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

["Martin v. Löwis"]

> 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