[Python-3000] pre-PEP: Procedure for PEPs with Backwards-Incompatible Changes

[Guido van Rossum]

On 3/28/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> I'm not concerned about that.  Everyone here will ensure that if a
> feature should go into 2.x, it will.  The feature may be implemented
> first in 3k, the PEP may be 3xxx, but when it's ready, it will migrate
> to 2.x also.  This is important for moving to 3k.  We need to make the
> migration as simple as possible.  "Backporting" these features is one
> aspect of making it easier.
>
> No one is forgetting about 2.x by any means.  There seemed to be
> general consensus that there will be at least a couple more 2.x
> releases.  Or maybe that was just my view and no one disagreed. :-)

It's my view too.

But I think there will be less reason/opportunity to backport 3.x
features to 2.x than there were, for example, in the Zope 3 vs. Zope 2
situation. Zope 3 was a completely new system where much new ground
was broken, including new implementations of functionality that
already existed in Zope 2. When the new implementation in Zope 3 was
deemed mature enough and a serious improvement on the equivalent in
Zope 2, it was sometimes backported. The Python situation is a bit
different -- we're not starting with a reimplementation from the
ground up, and I expect that many of the new features will be
constrained by syntax or semantics (e.g. Unicode-only strings) which
will prevent them to be backported.

However, I suppose a bytes type might find its way into 2.6, and
perhaps also an alternate I/O stack.

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