[Python-Dev] Python 3000 Process (original) (raw)
Guido van Rossum guido at python.org
Mon Mar 20 05:30:13 CET 2006
- Previous message: [Python-Dev] Test
- Next message: [Python-Dev] Python 3000 Process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I see increased activity related to Python 3000. This is great, but there is some danger involved. Some of the dangers are: overloading developers; setting unrealistic expectations for what can be accomplished; scaring the more conservative user community; paralyzing developers who can't decide whether to wait for Python 3000 or not.
I'd like to address all these issues, but it may be better to first spend some time on creating a more streamlined process. Perhaps it's finally time to introduce a separate mailing list? If people agree, let's call it python-3000 at python.org. For many developers this won't make much of a difference (since they'll subscribe to both lists), but it will give people who are only concerned with Python 2.x a way to opt-out, and perhaps more importantly, it will make it clear whether any particular proposal is intended for Python 3000 or for Python 2.x.
I don't want to encourage people who are only interested in Python 3000 to opt-out from the 2.5 python-dev list, since Python 3000 is not being developed in a vacuum. It must be "a better Python" and that means it is informed to a large extent by recurring issues on python-dev (and c.l.py!).
The mailing list is only a small part of the new strategy. We need to start deciding on important meta-issues like:
What's the timeline? I don't expect to be setting a schedule now and sticking to it for the next five years. But we owe everybody out there who is watching some clarity about when Python 3000 can be expected, and how we plan to get there; there are widely differing estimates of how long it will take, and I don't want to scare users away or cause developers to hold their breath waiting for it (some of which I imagine is happening with Perl 6).
What's the upgrade path? Do we provide a conversion tool, or a compatibility mode, or both, or what? Will it be at all possible to write code that runs in Python 2.x (for large enough values of x) as well as in 3.0? This also touches upon the issue of parallel releases of Python 2.x and 3.x. My personal expectation (contrary to what MvL said recently) is that there will be several 2.x releases issued even after 3.0 is out; possibly 3.0 and 2.6 may coexist, and 2.7-2.9 may continue to evolve 2.x while 3.x is maturing. I've seen this used successfully in Perl (with 4->5) and Apache, and closer to home in Zope. Again, this is important in the light of how the transition is perceived in the world outside python-dev.
Will we do a grand library reform at the same time? Personally I see that as quite a separate issue; apart from some specific things like the stdio redesign, we could start the library reform in 2.6, or post-3.0, depending on how much energy there it.
What's the implementation strategy? I've started a branch where I plan to do some weeding out; but I've already found that the large amount of legacy code makes the weeding difficult. I may yet decide to switch to a sandbox model where only new code or carefully modernized old code is added (this is how Zope 3 was developed).
What's the procedure for proposing and new features? It may be time to start a new series of PEPs that focus exclusively on Python 3000. I'd like to reserve the numbers 3000-3099 for meta-PEPs (e.g. addressing the above questions) and 3100-3999 for feature PEPs.
Please don't respond with answers to these questions -- each of them is worth several threads. Instead, ponder them, and respond with a +1 or -1 on the creation of the python-3000 mailing list. We'll start discussing the issues there -- or here, if the general sense is not to split the list.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
- Previous message: [Python-Dev] Test
- Next message: [Python-Dev] Python 3000 Process
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]