[Python-Dev] 3.1 focus (was Re: for __future__ import planning)
kevin at bud.ca
Sun Oct 5 10:46:24 CEST 2008
On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
>> Setuptools declares dependencies, but does not add a Python version
>> 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
> like a permanent solution to me.
> As a permanent solution, you need to keep the problem statement in
> 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
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?
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"
More information about the Python-Dev