[Python-Dev] What should the focus for 2.6 be? (original) (raw)
Guido van Rossum guido at python.org
Sun Aug 20 17:24:16 CEST 2006
- Previous message: [Python-Dev] String formatting / unicode 2.5 bug?
- Next message: [Python-Dev] What should the focus for 2.6 be?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/)
- Previous message: [Python-Dev] String formatting / unicode 2.5 bug?
- Next message: [Python-Dev] What should the focus for 2.6 be?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]