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

[Neal Norwitz]

On 3/21/06, Thomas Wouters <thomas at python.org> wrote:
>
> 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.

I was thinking something very similar.  I originally hoped 2.6 (or
even 2.5!) would be the end of 2.x.  That doesn't seem right.  I think
there should definitely be a 2.6 and 2.7.  Possibly more 2.x, but that
would depend on the future and we shouldn't promise any.  2.x would
continue development/release as it has.

3.0 target near 2.6, about 2 years, maybe a bit longer, but definitely
long before 2.7.  I think 3.x should have releases every 4-6 months. 
These would be preview releases and might not even have a ton of
testing.  Although given the buildbot, I suspect all the previews will
work reasonably well.  The first 3.x release should be the first one
that rips out all the old behaviour and is reasonably minimal. 
Meaning all the Python and C crufty APIs, builtins, etc have been
removed, but (almost) nothing added.  As I said in a previous mail, I
hope to have everything ripped out by the end of April.

I wonder if we should call the 3.x series as 2.99.x for the
"pre-releases".  That would give us 99 tries to get it write, plus we
have an asymptote for 2.x. :-)

> > - 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.0
> to not worry about compatibility? :-) Then again, if it costs us little or
> nothing, it may be worth considering.

Definitely.

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

Perhaps we could have an extension module.  I have no idea if a source
conversion tool could work.  We kinda have to wait and see what 3k
ends up looking like.  We should at least try to flag constructs in a
tool.

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

Better to start sooner.  We could move everything to the new location,
but still keep the old locations around with pending deprecations as
Thomas says.  This way the 2.6 library should closely resemble 3.0.

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

I agree with Thomas at this point.  We should try to rip out as much
as possible.  If we don't like the result, we can always go to a
sandbox or another approach later.  I don't think it will be
necessary.  I do expect major components to be rewritten, like stdio,
but the new implementation can be moved into place atomically with
just that portion developed in a sandbox.

n