[Python-Dev] Some dull gc stats

[M.-A. Lemburg]

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/