Tim Peters wrote:
[MaL, replying to me, but presumably bonding with Martin again <wink>]
Patch level releases should *never* include new features (unless these are essential to fix a serious bug or a simple byproduct of a fix). I don't know where you got the impression that Python should move back to the 1.5 branch development process where patch levels added new features.
The pre-PBF Patch Czars generally took a hard "no new features!" stance, but it seems to be up in the air now.
I wonder why... just because Fossetts can't get back to solid ground doesn't mean we have to follow him ;-)
W/r to the PBF: at EuroPython we did a poll to see which version to base the PBF's activities on. The result was that a majority voted for Python 2.2 as first target.
Cool! Good choice.
Patch levels are there to stabilize a release, not make it more powerful.
This is one popular view, although there's plenty of wiggle room in what "stabilize" means (e.g., is it "stabilizing" to port Python to a new platform? to speed a bottleneck? to add a new encoding? etc).
"Stabilize" should mean to make triggering bugs in a Python release less likely. I don't think that porting to a new platform falls under this definition, a new encoding might (but then only if the encoding is so popular that people consider its absence a bug), performance tweaks are probably within range if they are in the micro-optimization area and hidden within the interpreter. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/