[Python-3000] Premature optimization and all that

[Guido van Rossum]

Over lunch with Neal we came upon the topic of optimization and Python 3000.

It is our strong opinion that in this stage of the Py3k project we
should focus on getting the new language spec and implementation
feature-complete, without worrying much about optimizations.

We're doing major feature-level surgery, e.g. int/long unification,
str/unicode unification, range/xrange unification, keys() views, and
many others. Keeping everything working is hard work in and of itself;
having to keep it as fast as it was through all the transformations
just makes it that much harder.

if Python 3.0 alpha 1 is twice as slow as 2.5, that's okay with me; we
will have another year to do performance measurements and add new
optimizations in the ramp-up for 3.0 final. Even if 3.0 final is a bit
slower than 2.5 it doesn't bother me too  much; we can continue the
tweaks during the 3.1 and 3.2 development cycle.

Note: I'm note advicating wholesale proactive *removal* of
optimizations. However, I'm allowing new features to slow down
performance temporarily while we get all the features in place. I
expect that the optimization possibilities and needs will be different
than for 2.x, since some of the fundamental data types will be so
different.

In particular, I hope that Martin's int/long unification code can land
ASAP; it's much better to have this feature landed in the p3yk branch,
where everyone can bang on it easily, and learn how this affects user
code, even if it makes everything twice as slow. This seems much
preferable over having it languish in a separate branch until it's
perfect.

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