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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4