Re: [Python-Dev] 3.1 focus (was Re: for __future__ import planning)
On Sun, Oct 5, 2008 at 6:59 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Setuptools declares dependencies, but does not add a Python version >> requirement, >> like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/) >> with a new metadata called 'Requires Python' >> >> Even if the problem is fixed in short term with a Trove classifier, > > Why would that be a short-term fix? It would work for the entire life > time of Python 3, and can be easily extended for Python 4, so it sounds > like a permanent solution to me. > > As a permanent solution, you need to keep the problem statement in mind, > though: to allow people to determine whether a package works with Python 3. > >> the metadata of a package should provide this information imho. > > Well, the classifiers *are* part of the metadata of the package. Yes and they are redundant to other metadata, like the licence for instance.. So maybe the problem is the other way: some specific metadata should be removed since they are expressed in the classifier medatata. (e.g. only in one place) There should be one-- and preferably only one --obvious way to do it. Regards Tarek ___ 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
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)
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote: Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/ ) with a new metadata called 'Requires Python' Even if the problem is fixed in short term with a Trove classifier, Why would that be a short-term fix? It would work for the entire life time of Python 3, and can be easily extended for Python 4, so it sounds like a permanent solution to me. As a permanent solution, you need to keep the problem statement in mind, though: to allow people to determine whether a package works with Python 3. The Setuptools dependencies fields are only for declaring library dependencies, not dependencies such as the Python interpreter. 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. There is a "Py Version" field for file uploads (which I'd really like to tweak the UI to read "Python Version"), 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). 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? foobar-1.0-py2.6.tar.gz foobar-1.0-py3.0.tar.gz Or should it be something like? foobar-1.0.tar.gz # Python 2 foobar-1.1.tar.gz # Python 3 Well, writing out that last example looks wrong to me, since 1.0 -> 1.1 suggests bug fixes and API changes to the package. But someone could be thinking, "1.0 supports the Python 2 API and 1.1 supports the Python 3 language API". So at any rate it'd be good to make the way to handle this explicit in the (yet to be created) "2to3 central" documentation resource. ___ 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:
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
print( wc_status_kind_map[ pysvn.wc_status_kind.unversioned ] )
KeyError:
___
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
Re: [Python-Dev] porting pycxx and pysvn to python 3.0 hit a problem
Barry Scott wrote: 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' ) 2 key added False 1 -586300914 2 failed 2 key replaced False 1 -586300911 2 failed 2 key unversioned False 0 -586300916 2 failed Given that p.we.x seems to always return the same object (since the hashes, which which appear to be ids, are the same), an __eq__ method (which gets called in preference to __cmp__), possibly inherited, that always return False is the only thing I can think of. (Hence Martin's question, I presume). I have no idea, however, how porting could make that happen. tjr ___ 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] [Fwd: In Python 2.6, bytes is str]
This does make it look rather as though bytes == str was a decision whose consequences weren't fully appreciated before implementation. Was this horror anticipated? regards Steve Original Message Subject: In Python 2.6, bytes is str Date: Sun, 05 Oct 2008 22:30:17 -0700 From: Bryan Olson <[EMAIL PROTECTED]> Organization: at&t http://my.att.net/ To: [EMAIL PROTECTED] Newsgroups: gmane.comp.python.general Python 3 has the 'bytes' type, which the string type I've long wanted in various languages. Among other advantages, it is immutable, and therefore bytes objects can be dict keys. There's a mutable version too, called "bytearray". In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 assignment presents some pitfalls. Be aware. Consider constructing a bytes object as: b = bytes([68, 255, 0]) In Python 3.x, len(b) will be 3, which feels right. In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'. I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's another Python release between 2.6 and 3.gold, I'd advocate removing the pre-defined 'bytes', or maybe defining it as something else. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list -- 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] [Fwd: In Python 2.6, bytes is str]
On Sun, Oct 5, 2008 at 11:43 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > This does make it look rather as though bytes == str was a decision > whose consequences weren't fully appreciated before implementation. > Well, you could say that about almost any change. > Was this horror anticipated? I didn't anticipate it. > > regards > Steve > > Original Message > Subject: In Python 2.6, bytes is str > Date: Sun, 05 Oct 2008 22:30:17 -0700 > From: Bryan Olson <[EMAIL PROTECTED]> > Organization: at&t http://my.att.net/ > To: [EMAIL PROTECTED] > Newsgroups: gmane.comp.python.general > > > Python 3 has the 'bytes' type, which the string type I've long wanted in > various languages. Among other advantages, it is immutable, and > therefore bytes objects can be dict keys. There's a mutable version too, > called "bytearray". > > In Python 2.6, the name 'bytes' is defined, and bound to str. The 2.6 > assignment presents some pitfalls. Be aware. > > Consider constructing a bytes object as: > >b = bytes([68, 255, 0]) > > In Python 3.x, len(b) will be 3, which feels right. > > In Python 2.6, len(b) will be 12, because b is the str, '[68, 255, 0]'. > > > I'm thinking I should just avoid using 'bytes' in Python 2.6. If there's > another Python release between 2.6 and 3.gold, I'd advocate removing > the pre-defined 'bytes', or maybe defining it as something else. I think it needs to be made clear that bytes is there for type compatibility (e.g., ``isinstance(ob, bytes)``). And the bytes literals work how you would expect. What I would like to know if there are any other gotchas beyond the constructor as all of the other uses act as you would expect. -Brett ___ 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
