Benjamin Peterson wrote:

I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.

Hey! That was my idea! I told you the very same idea on IRC a week ago. Shame on you! :) I'm +1 on the proposal. Let's focus on stability and performance for the next release. But before we start planning the next release we need to find a way to sync the development. Soon we have to apply fixes to up to four (again FOUR) branches: 2.6, 2.7, 3.0 and 3.1. We don't have to merge as many code as we did during the py3k phase. But it's still lots of work and we need all the (technical) help we can get. Christian

On Fri, Oct 3, 2008 at 3:56 PM, Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:

...

So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)

I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.

There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.

I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".

+1 from me. I think 2.7/3.1 should be used as a chance to get our testing framework straightened out and have those releases be extremely rock-solid (especially 2.7 as it might be the last in the 2.x series). Oh, and getting import rewritten in pure Python for 3.1 of course. =)

I would really like to see us adopt a distributed version control system.

Along the lines of making 2.7/3.1 very stable releases, I would love to use the time to clean up our workflow. To me that means cleaning up the workflow on the issue tracker and getting on to a DVCS to make it as easy as possible for people to contribute patches and for us to do reviews.

I want our maintenance branches to always be in a releasable state. I want to be confident enough about the tree to be able to cut a point release at any time. I want to release a new point release from the maint branches once a month.

Wow! I guess release.py is going to get really automated then. =) That or you are going to manage to con more of us to help out (and even cut the release ourselves).

Christian rightly points out that with four active trees, we're going to a pretty big challenge on our hands. How do other large open source projects handle similar situations?

Beats me. Are that many projects crazy enough to have that many active branches? -Brett

Brett Cannon writes:

Beats me. Are that many projects crazy enough to have that many active branches?

Any project using branch-driven development has many active branches. Our specificity is that we must maintain in sync two branches (trunk, py3k) which have widely diverged from each other. Thus, merges are often non-trivial. Regards Antoine.

Barry Warsaw schrieb:

On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:

...

So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)

...

I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.

There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.

I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".

Especially 3.1 should also be a release where we focus as much on the community as on the code. There are many people out there for whom Python 3, as an incompatible language, is not an easy step to make, especially those with huge 2.x codebases on their hands. They have two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them. We need to make 2to3 and related tools reliable and do more showcases of porting, like Martin did with Django, so that people have real-world examples at their disposal, by which they can estimate their own porting needs. (Waiting for the extended community to deliver such examples may be a mistake.) We also need to commit to help people with porting. I propose a new mailing list (e.g. python3-porting), parallel to python-list, specifically for people going that way. I think it will help to focus the community effort of getting Python 3 off the ground. Last not least, there should be a *central* location on python.org where specifically all resources on 2->3 transition are collected. Talks, documents, links, and some crucial information many people seem to miss, such as how long the 2.x series will at least be maintained. They depend on this. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers...

Can you propose a spec? Regards, Martin

Antoine Pitrou wrote:

Martin v. Löwis writes:

...

...

This may be more complicated than it sounds, because you'd probably add a very general requirement-indicating feature to PyPI, not merely a 'supports 3.0' Boolean on each record, and requirements are actually pretty complicated: alternative packages, specific version numbers... Can you propose a spec?

Setuptools already has a syntax for declaring requirements. http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies

That is underspecified for the issue at hand: What *specifically* should PyPI look for to determine 3.0 support in a package, and how *specifically* should it display that? An alternative to specifying dependencies would be to specify a classifier, e.g. Programming Language :: Python :: 3 or Programming Langauge :: Python3 Then, no changes to PyPI are needed (except for adding the classifier to the database), and searching for Python-3-supporting packages could go through http://pypi.python.org/pypi?%3Aaction=browse Regards, Martin

On Sat, Oct 4, 2008 at 12:45 AM, Georg Brandl wrote:

Barry Warsaw schrieb:

...

On Oct 3, 2008, at 5:26 PM, Benjamin Peterson wrote:

...

So now that we've released 2.6 and are working hard on shepherding 3.0 out the door, it's time to worry about the next set of releases. :)

...

I propose that we dramatically shorten our release cycle for 2.7/3.1 to roughly a year and put a strong focus stabilizing all the new goodies we included in the last release(s). In the 3.x branch, we should continue to solidify the new code and features that were introduced. One 2.7's main objectives should be binding 3.x and 2.x ever closer.

There are several things that I would like to see us concentrate on after the 3.0 release. I agree that 3.1 should be primarily a stabilizing release. I suspect that we will find a lot of things that need tweaking only after 3.0 final has been out there for a while.

I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".

Especially 3.1 should also be a release where we focus as much on the community as on the code. There are many people out there for whom Python 3, as an incompatible language, is not an easy step to make, especially those with huge 2.x codebases on their hands. They have two problems: The libraries they depend on aren't ported, and the KLOC of code they care about are hard and tedious work to port, not to mention that it typically isn't viewed as productive work by those who pay them.

We need to make 2to3 and related tools reliable and do more showcases of porting, like Martin did with Django, so that people have real-world examples at their disposal, by which they can estimate their own porting needs. (Waiting for the extended community to deliver such examples may be a mistake.)

We also need to commit to help people with porting. I propose a new mailing list (e.g. python3-porting), parallel to python-list, specifically for people going that way. I think it will help to focus the community effort of getting Python 3 off the ground.

This is a good idea; python-help for porting.

Last not least, there should be a *central* location on python.org where specifically all resources on 2->3 transition are collected. Talks, documents, links, and some crucial information many people seem to miss, such as how long the 2.x series will at least be maintained. They depend on this.

That seems reasonable if someone gets around to doing it. =) -Brett

Well, since for >95% of the (potential) Py3k users it is more important than e.g. the import rewrite in Python (no stab at you intended, Brett), it is something someone will have to get around to doing.

I'm not excusing myself; in fact, I'd be happy to work on this, but overall the team "Python 3 advocacy and support" should consist of more than one person.

I think this has time. I'm (now) confident that people will port to Python 3 sooner rather than later, just because it's there. In fact, we have to be careful not to talk too many people into porting, since there will be some glitches which need to be resolved, and may not get resolved before 3.2 or so. So people with a natural wariness are advised to trust this wariness, or else all their concerns become self-fulfilling prophecies. Regards, Martin

2008/10/4 Brett Cannon :

So the mailing list is a good idea. Perhaps it should just be python-porting so that it can also be used for people who have problems with minor releases?

+1. I'd try to help on that list, also. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

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. Regards, Martin

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.

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/

[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

...

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

Martin v. Löwis writes:

Although it would be possible, I think it's not appropriate.

I also think it's inappropriate. We want people to know about the existence of Python 3, and the best for that is to have Python 3-related information in the standard PyPI site where people look for Python 2.x packages. Regards Antoine.

On Sat, Oct 4, 2008 at 00:56, Barry Warsaw wrote:

I think 2.7 should continue along the path of convergence toward 3.x. The vision some of us talked about at Pycon was that at some point down the line, maybe there's no difference between "python2.9 -3" and "python3.3 -2".

I like that. Do we know what the next "hurdle" would be? The testing I have done seems to indicate that one major area is handling of binary file data that may or may not be binary. Is a real bytes type (and not just an alternate spelling for str) a possibility? It may be that this isn't a problem in practice, I don't know yet. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64