[Python-3000] [Python-Dev] Python 3000 Process

[Thomas Wouters]

On 3/20/06, Guido van Rossum <guido at python.org> wrote:
>
> 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).


Personally, I like the idea of Python 3.0 being released somewhere between
2.6 and 2.7, as you suggested at PyCon. That puts it between 1.5 and 3 years
from now, given the usual release schedules. From what I can see now, that
should be enough time to work out the major changes in 3.0. Maybe we should
bill 3.0 as a 'developer release', urging extension/module-writers to adapt
their code to 3.0 but not pushing it for general use. On the other hand,
maybe it's better to make many pre-releases of 3.0, to give people a chance
to look at 3.0 and to give developers (including ourselves) a chance to
figure out how to upgrade (or facilitate upgrading) libraries, extensions
and applications.


> - 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?


I would like Pythonic code to be usable in both 2.x (where x is, say, 6 or
higher) and 3.0, but 3.0 shouldn't need to worry too much about it. A
compatibility mode is probably a bad idea -- isn't the whole reason
for 3.0to not worry about compatibility? :-) Then again, if it costs
us little or
nothing, it may be worth considering.

As for a conversion tool, it's a nice idea, but I wonder how well it'll work
in practice. Take dict.items() returning an iterator; how are you going to
detect it, let alone convert it? You can 'convert' it by translating it to
'list(dict.items())', but it won't result in high quality code. Maybe a
'change highlighter', which runs through code and detects things that might
have changed in Python 3.0, is a more workable idea. I do believe that's the
minimum we should aim for, though.

Or, if source-inspection turns out to be too hard, have a
backward-compatibility-aware 3.0, which can warn that something will behave
differently than 2.x. (Maybe that's what you meant by 'compatibility mode')
I wouldn't call it 'python' or 'python3' though, but keep it separate from
python. It would have to replace a number of types with proxy-types that
also check various uses.

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.


I think the choice for parallel releases is a no-brainer, although we'll
have to see how it turns out in practice. If 3.0 is a smash hit with an easy
upgrade path, we'll need less 2.x releases than if upgrading ends up being a
labourious process.


> - 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.


Agreed. We can certainly add new modules/names to 2.6 to make them
forward-compatible and add pending-deprecationwarnings to the old names.

- 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).


Hm, I don't feel that we need to throw out that much code. If you want to
re-implement Python from scratch (with copious copy-pasting from 2.x) a
sandbox model might make more sense, but then 1.5-3 years is quite
unrealistic, and we'd also need to consider the C API stability. I'd much
rather go for rigorous reviews and weeding of the existing source, than
copying reviewed code until we have a working interpreter.

- 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.


Aye. I would like to suggest we document all changes, even when they are
no-brainers that have been on the wishlist for years and don't fit the PEP
style: making dict.keys/items/values return iterators, making -tt the
default, removing the emacs/vi-tabsize-comment-hack from the parser, making
all strings unicode, etc. In the end, a 'best practices' document describing
how to write 2.x-and-3.x-compatible code may come in handy, too (but that
can't be written until many features are fleshed out.)

--
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060321/e6a0c0eb/attachment.html