[Python-Dev] What should the focus for 2.6 be?

[Guido van Rossum]

I've been thinking a bit about a focus for the 2.6 release.

We are now officially starting parallel development of 2.6 and 3.0. I
really don't expect that we'll be able to merge the easily into the
3.0 branch much longer, so effectively 3.0 will be a fork of 2.5.

I wonder if it would make sense to focus in 2.6 on making porting of
2.6 code to 3.0 easier, rather than trying to introduce new features
in 2.6. We've done releases without new language features before;
notable 2.3 didn't add anything new (except making a few __future__
imports redundant) and concentrated on bugfixes, performance, and
library additions.

Some projects that could be undertaken in 2.6:

- add warnings when apply() is used
- add warnings when string exceptions or non-BaseException-derived
exceptions are used (this is already planned in PEP 252, which has a
very specific roll-out plan)
- add warnings when has_key() is used
- add warnings when the result of dict.keys(), .values(), .items() is
used for anything else than iterating over it
- a warning if a class defines has_key() but not __contains__().
- add __contains__ to dbm and gdbm
- add warnings to modules and built-ins that will die in 3.0

Some of these warnings should be suppressed by default, but enabled by
a command line option. We should also do the work on the standard
library to avoid the warnings: get rid of apply(), use 'x in d'
instead of 'd.has_key(x)', etc. I've recently done some of this work
in the 3.0 branch (e.g. dbm/gdbm are fresh in my memory).

Another area that could use a lot of work (and from which 3.0 could
also benefit directly) is converting all unit tests to using either
unittest.py or doctest.py. There are still at least 40 tests written
in the old "compare the output with one we prepared earlier" style.

Of course, if people are chomping at the bit to implement certain new
features (and those features are generally approved of) then I don't
want to stop them; but I would recommend that our effort may better be
focused on smoothing the 2.6/3.0 transition rather than looking for
new features to add to 2.6.

I am often approached by people who object against this or that
feature proposal not because they dislike the proposed feature in
particular, but because they believe Python is already large enough,
and they worry that if we keep adding features at the current pace, it
will soon become too unwieldy, and hence harder to learn or to keep in
one's brain. I am very sympathetic to this concern (and you should be
too!). This is one of the reasons that so much of the Python 3000 work
is about ripping out old stuff and simplifying / unifiying things.
Dropping two common data types (long and unicode -- of course they
will really be merged into their simpler counterparts int and str, but
it means much less to learn/remember) is one example. Ripping out
classic classes and string exceptions another. Removing dead library
modules a third.

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