[Python-Dev] 3.1 focus (was Re: for __future__ import planning)

[Kevin Teague]

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.