[Python-ideas] Code version evolver

[Stephen J. Turnbull]

francismb writes:

 > Trying to keep a single code base for 2/3 seems like a good idea
 > (may be the developer just cannot change to 3 fast due how big the
 > step was) but that also have the limitation on how far you can go
 > using new features.

This doesn't work very well: you can't use 3 at all until you can use
3 everywhere.  So the evolutionary path is

0.  Python 2-only code base
1.  Part Python 2-only, part Python 2/3 code base (no new features
    anywhere, since everything has to run in Python 2 -- may require
    new test halters for component testing under Python 3, and system
    test has to wait for step 2)
2.  Complete Python 2/3 code base
3a. Users use their preferred Python and developers have 2/3 4ever!
    (All limitations apply in this case. :-( )
3b. Project moves to Python 3-only.

So what most applications did is branch 2 vs. 3, do almost all new
development on 3 (bugfixing on both 2 and 3 of course, and maybe
occasionally backporting a few new features to 2), and eventually
(often as soon as there's a complete implementation for Python 3!)
stop supporting Python 2.  Only when there was strong demand for Step
3a (typically for popular libraries) did it make sense to spend effort
satisfying the constraints of a 2/3 code base.

 > Once you're just on the 3 series couldn't such 2to3 concept also help to
 > speed up ? (due the 'backwards-compatibility issue')

Not really.  For example, addition of syntax like "async" and "yield"
fundamentally changes the meaning of "def", in ways that *could not*
be fully emulated in earlier Pythons.  The semantics simply were
impossible to produce -- that's why syntax extensions were necessary.

What 2to3 does is to handle a lot of automatic conversions, such as
flipping the identifiers from str to bytes and unicode to str.  It was
necessary to have some such tool because of the very large amount of
such menial work needed to change a 2 code base to a 3 code base.  But
even so, there were things that 2to3 couldn't do, and it often exposed
bugs or very poor practice (decode applied to unicode objects, encode
applied to bytes) that had to be reworked by the developer anyway.

The thing about "within 3" upgrades is that that kind of project-wide
annoyance is going to be minimal, because the language is mostly
growing in power, not changing the semantics of existing syntax.  Such
changes are very rare, and considered extremely carefully for
implications for existing code.  In a very few cases it's possible to
warn about dangerous use of obsolete syntax whose meaning has changed,
but that's very rare too.

In some cases *pure additions* to the core will be available via "from
__future__ import A", which covers many of the cases of "I wish I
could use feature A in version X.Y".  But this kind of thing is
constrained by core developer time, and developing a 3.x to 3.y
utility is (IMO, somebody else is welcome to prove me wrong! :-) way
past the point of zero marginal returns to developer effort.

It's an interesting idea, but I think practically it won't have the
benefits you hope for, at least not enough to persuade core developers
to work on it.

Steve


-- 
Associate Professor              Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/     Faculty of Systems and Information
Email: turnbull at sk.tsukuba.ac.jp                   University of Tsukuba
Tel: 029-853-5175                 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN