Re: [Python-Dev] if-syntax for regular for-loops
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 PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
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 could, in theory, be replaced with the ellipsis notation often used in pseudo-code to denote real code goes here. I don't think pursuing such a switch is actually a good idea - 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. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] if-syntax for regular for-loops
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. :-) Indeed :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 issue of how the page is rendered. Hence I asked for a full specification. There is a Py Version field for file uploads (which I'd really like to tweak the UI to read Python Version) Feel free to submit a patch (or perhaps just a bug report). maybe if you could specify for uploads of the source type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules). I think that deviates from the subject, which is 3.1 focus, and AMK's request to let people find out whether a package runs on Python 3. Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run 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? It all depends on how you do the porting. If all it takes to run the program through 2to3 to make it port correctly, I recommend to use the build_py_2to3 build step of distutils in 3.0. Then the same source can be installed for 2.x and 3.x, with no modifications. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 Categories. That's an issue of how the page is rendered. Hence I asked for a full specification. There is a Py Version field for file uploads (which I'd really like to tweak the UI to read Python Version) Feel free to submit a patch (or perhaps just a bug report). maybe if you could specify for uploads of the source type the Python compatability of the source file? Even without Python 3 it would be nice to upload a source file and indicate that you've used a Python 2.5 or 2.6ism in your code (or made use of newer standard library modules). I think that deviates from the subject, which is 3.1 focus, and AMK's request to let people find out whether a package runs on Python 3. Although this raises the question, what is the recommended practice for version numbering for distributions attempting to support both Python 2 and 3? Say I have a distribution that I've made work with Python 2.6 and can run 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? It all depends on how you do the porting. If all it takes to run the program through 2to3 to make it port correctly, I recommend to use the build_py_2to3 build step of distutils in 3.0. Then the same source can be installed for 2.x and 3.x, with no modifications. 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. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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? 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 Or should it be something like? foobar-1.0.tar.gz # Python 2 foobar-1.1.tar.gz # Python 3 The problem here is that I can foresee libs or apps that have a mixed path, starting to support Py 3 at some point, and deprecating the Py 2 support after a while: foobar-1.0.tar.gz # Py 2 foobar-1.1.tar.gz # Py 2 3 foobar-1.2.tar.gz # Py 2 3 foobar-1.3.tar.gz # Py 2 3 foobar-1.4.tar.gz # Py 2 3 foobar-1.5.tar.gz # Py 3 Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
[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 automatically porting updates to the Py3Pi website. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 pypi.python.org/python3 (say), along with /simple3 and /packages3. I find it inappropriate for two reasons: over time, Python 2 will disappear, and then we are left with the python3 URLs (similar how Microsoft now needs to put 64-bit binaries into the system32 folder). In addition, packages that do support both versions need to register twice, upload twice, etc. In any case, if that route is chosen, we have to adjust distutils before the 3.0 release is made. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
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 foobar_py3-1.0.tar.gz and register a second project foobar_py3 in PyPI. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem
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',
pysvn.wc_status_kind.unversioned: '?',
}
This fails:
wc_status_kind_map[ pysvn.wc_status_kind.unversioned ]
With:
KeyError: wc_status_kind.unversioned
Clearly I have a bug in the implementation of pysvn.wc_status_kind and
could do with some suggestions on what to check please.
I've assumed that if my objects support tp_hash and tp_compare
they can be used as keys to a dictionary. My test scripts shows
hash() and cmp() working.
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?
Barry
- a.py
import pysvn
wc_status_kind_map = {
pysvn.wc_status_kind.replaced: 'R',
pysvn.wc_status_kind.unversioned: 'U',
}
print( 'hash wc_status_kind', hash( wc_status_kind ) )
print( 'hash replace', hash( pysvn.wc_status_kind.replaced ) )
print( 'hash unversioned', hash( pysvn.wc_status_kind.unversioned ) )
print( 'cmp unversioned, unversioned', cmp
( pysvn.wc_status_kind.unversioned, pysvn.wc_status_kind.unversioned ) )
print( 'cmp unversioned, replaced', cmp
( pysvn.wc_status_kind.unversioned, pysvn.wc_status_kind.replaced ) )
print( 'cmp replaced, unversioned', cmp
( pysvn.wc_status_kind.replaced, pysvn.wc_status_kind.unversioned ) )
for key in wc_status_kind_map.keys():
print( '1 key', key, key in wc_status_kind_map, cmp( key,
pysvn.wc_status_kind.unversioned ), hash( key ) )
try:
print( '1 lookup', wc_status_kind_map[ key ] )
except:
print( '1 failed' )
for key in [pysvn.wc_status_kind.added,
pysvn.wc_status_kind.replaced,
pysvn.wc_status_kind.unversioned]:
print( '2 key', key, key in wc_status_kind_map, cmp( key,
pysvn.wc_status_kind.unversioned ), hash( key ) )
try:
print( '2 lookup', wc_status_kind_map[ key ] )
except:
print( '2 failed' )
print( wc_status_kind_map[ pysvn.wc_status_kind.unversioned ] )
Output ---
$ python3.0 a.py
hash wc_status_kind -586300918
hash replace -586300911
hash unversioned -586300916
cmp unversioned, unversioned 0
cmp unversioned, replaced -1
cmp replaced, unversioned 1
1 key replaced True 1 -586300911
1 lookup R
1 key unversioned True 0 -586300916
1 lookup U
2 key added False 1 -586300914
2 failed
2 key replaced False 1 -586300911
2 failed
2 key unversioned False 0 -586300916
2 failed
Traceback (most recent call last):
File a.py, line 32, in module
print( wc_status_kind_map[ pysvn.wc_status_kind.unversioned ] )
KeyError: wc_status_kind.unversioned
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
