Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

[Neal Norwitz]

On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <python at rcn.com> wrote:
>
> This is what I mean about the patch taking on a life of its own.  It's
> an optimization patch that slows down METH_O and METH_NOARGS.  It's a
> incremental change that throws away backwards compatibility.  It's a
> simplification that introduces a bazillion new code paths.  It's a
> simplification that can't be realized until 3.0.

I've been thinking about how to move towards 3.0.  There are many
changes that are desirable and unlikely to occur prior to 3.0.  But if
we defer so many enhancments, the changes will be voluminous,
potentially difficult to manage, and possibly error prone.  There is a
risk that many small warts will not be fixed, only because they fell
through the cracks.

I thought about making a p3k branch in CVS.  It could be worked on
slowly and would be the implementation of PEP 3000.  However, if a
branch was created all changes would need to be forward ported to it
and it would need to be kept up to date.  I know I wouldn't have
enough time to maintain this.

The benefit is that people could test the portability of their
applications with 3.0 sooner rather than later.  They could see if the
switch to iterators created problems, or integer division, or
new-style exceptions, etc.  We could try to improve performance by
simplifying architecture.  We could see how much a problem it would be
to (re)move some builtins.

Any ideas how we could start to realize some benefits of Py3.0 before
it arrives?  I'm not sure if this is worth it, if it's premature, or
if there are other ways to acheive the goal of easing transition for
users and simplifying developers tasks (by spreading over a longer
period of time) and reducing the possibility of not fixing warts.

Neal