[Python-3000] how to transition 2.X code to 3.0 code

[Guido van Rossum]

On 3/24/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 3/24/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> > I'm well aware that Python 3000 doesn't aim to be backwards compatible,
> > but I would prefer if we could refrain from subtly changing the behaviour
> > of existing constructs in way that breaks all existing use, and makes it un-
> > necessarily hard to convert old code (whether by hand or by machine).
>
> Agreed.  I wonder what the plan is for the transition?

That's the agenda of this list! The users need to speak up.

> Things like
> changing the semantics of the for-loop else-clause are actually
> relatively easy to flag since they can be spotted easily with the AST,
> and *all* current uses of the else-clause would be wrong.

Regarding this particular feature proposal, I'd like to strongly
discourage it. I don't think it's well thought out; it looks more like
an ad-hoc response to the issue brought up by Ian Bicking. If you
disagree, please write a well-argued PEP.

> However, flagging things like "expects a list from dict.items instead
> of an iterator" might be harder to do.  Some uses (for-loops,
> list-comps and genexps) are still perfectly fine while other uses
> (indexing, getting the len) aren't.  I think most of these should
> raise an exception pretty quickly, but if any of them don't, that
> would make me pretty nervous when transitioning code.

Right. Unfortunately we're already bound to have incompatibilities
that will give existing code new meanings that are hard to detect by
source code inspection only -- e.g. i/j will return a float when i and
j are ints, and you can't always tell whether any particular use of
x/y will ever involve two ints.

Python 3000 *will* be backwards incompatible, and sometimes it will be
awkward to convert code. The question I lay in front of the community
is, how much incompatibility can we handle? And what will the
transition strategy be? Someone needs to own this discussion topic,
start collecting ideas and feedback, and draft a PEP that will guide
the Python 3000 feature specification process.

One possibility is that every feature PEP is required to contain a
section on compatibility issues and how the transition is handled.
Sometimes the only reasonable answer will be "Some fraction of code
will break and users will have to debug this on a per-case basis." (I
imagine this is the most sensible approach in the case of the
elimination of classic classes, which have a subtly different multiple
inheritance pattern.) But hopefully in most cases we can provide tools
to scan old code for potential issues (e.g. I wrote one long ago for
int division) or even a conversion tool.

But all this needs to be guided by an explicit policy, which hasn't
been defined yet. Without an explicit policy we'll have never-ending
discussions about whether a particular incompatibility is acceptable
or not.

> I wonder if it would be worth having a branch of python-3000 at some
> point that inserts warning code on all constructs that changed (e.g.
> all calls to dict.items).  I have a suspicion that this would generate
> a lot of false-positives, but maybe it would still be worthwhile...

That's one proposal. I don't know how feasible it is, or if there are
better solutions. Clearly we need to think about this more. Perhaps
you would like to (co-)own the transition strategy topic?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)