Eric Smith wrote:
I think it's a little too cute, and 'pass' is preferable.
Agreed - it was just a little surreal to put the ... in as my usual
pseudo-code stuff happens here marker, only to realise what I had
written was still executable Py3k code.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL
Matthew Hawkins wrote:
If there's another way of doing this I'd like to hear it.
The pass statement is still the right way to denote an empty block (the
compiler is already able to detect that and optimise the code
appropriately).
My tangential comment was based on the fact that this keyword
Nick Coghlan wrote:
it was
just odd to notice that the Py3k interpreter would quite happily execute
the example code in my postscript when I had really only intended to
write it as pseudo-code with sections missing.
Well, they do say that Python is executable
pseudocode. :-)
--
Greg
Greg Ewing wrote:
Nick Coghlan wrote:
it was
just odd to notice that the Py3k interpreter would quite happily execute
the example code in my postscript when I had really only intended to
write it as pseudo-code with sections missing.
Well, they do say that Python is executable
pseudocode.
A problem with overloading the Categories field with Python version
compatability information is that it makes for a poor user-interface. On
the release page for a package, I'd rather see a Python Version field
than having to look through a potentially large list of Categories.
That's an
Martin v. Löwis wrote:
A problem with overloading the Categories field with Python version
compatability information is that it makes for a poor user-interface. On
the release page for a package, I'd rather see a Python Version field
than having to look through a potentially large list of
2008/10/5 Kevin Teague [EMAIL PROTECTED]:
on Python 3 after running it through 2to3. The source code is different so
that to me suggests different version numbers - but the API will be the
same, so maybe the same version number should be used? That is should there
be?
[Steve Holden]
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
It would be nice if we had a way of marking Py2.6 recipes that still
work when run through 2-to-3 and then
Of course there is also the option of treating Python 3 as a different
language, and having a Py3Pi website as well. This might not be as
wasteful as it at first seems.
Although it would be possible, I think it's not appropriate.
It would be fairly easy to implement, though: just create
foobar-1.0-py2.6.tar.gz
foobar-1.0-py3.0.tar.gz
More likely, in this way:
foobar-1.0-py2.tar.gz
foobar-1.0-py3.tar.gz
How do you implement this in distutils? People probably won't rename
the files from how sdist names them. So it's more likely that they
come up with things like
I have a version of PyCXX ported to python 3.0 rc1 and its passing
its tests.
I'm porting pysvn to python 3.0 rc1 and hit an odd problem.
Given this dict:
wc_status_kind_map = {
pysvn.wc_status_kind.added: 'A',
pysvn.wc_status_kind.replaced: 'R',
Why does key in wc_status_kind_wc work when I use an object returned
by keys() by not when I use pysvn.wc_status_kind.unversioned?
This is too little detail to come up with an explanation. Do your
objects support __eq__.
Regards,
Martin
___
12 matches
Mail list logo
