[Python-Dev] Suggestion: new 3 release with backwards compatibility

David Lyon david.lyon at preisshare.net
Wed Jan 6 01:36:24 CET 2010


Hi Ian,

> The only workable workflow I've seen people propose for maintaining a
> single
> codebase with compatibility across both 2 and 3 is to use such tricks,
> with
> aliases to suppress some 2to3 updates when they are inappropriate, so that
> you can run 2to3 on install and have a single canonical Python 2 source.
>  Python 2.7 won't help much (even though it is trying) as the introduction
> of non-ambiguous constructions like b"" aren't compatible with previous
> versions of Python and so can't be used in many libraries (support at
> least
> back to Python 2.5 is the norm for most libraries, I think).
>
> Also, running 2to3 on installation is kind of annoying, as you get source
> that isn't itself the canonical source, so to fix bugs you have to look at
> the installed source and trace it back to the bug in the original source.
>
> I suspect a reasonable workflow might be possible with hg and maybe patch
> queues, but I don't feel familiar enough with those tools to map that out.

That's why I am saying that we need a Code-Repository: section in PEP-345
Metadata.

Let package developers keep two branches in SCM. One for 2.x and one for 3.x

Let them backport features from their 3.x development series to their 2.x
code base. In exactly the same way that it is done in so many other
developments today.

Keeping multiple branches of code is a very common thing these days. And
there are tools in the outside world (bzr,svn,mercurial) that allow us to
do it very easily.

Let's have that support in python; it will make life easier.

David











More information about the Python-Dev mailing list