[Python-Dev] Some dull gc stats
Fri, 5 Jul 2002 07:30:16 +0200
On Tuesday 02 July 2002 21:06, Tim Peters wrote:
> > I understand that it is not a requirement anymore that changes to
> > Python 2.2 are "pure bugfixes". Instead, people expect that Python 2.2
> > evolves and continues to grow new features, as long as they are
> > "strictly backwards compatible".
> Alex made a case here for "new features", but the Python Business Forum
> hasn't shown interest in that.
As a Python Business Forum member and board member, I think I can
state that if a (business) case is indeed made, the PBF interest is there.
> Like most businessfolk, I expect they'll
> ignore such issues until someone discovers that the lack of a new feature
> is putting them out of business <0.8 wink>.
I suspect instead that a businessperson clever enough to pick Python
rather than heavily-hyped Java or widely-popular Perl or PHP is most
likely to be an unusually clever businessperson, with some level of
perception of what programming productivity is worth and how to get it.
> > For any user-visible feature, it is normally debatable whether it is
> > "strictly backwards compatible", since it is, by nature, a change in
> > observable behaviour.
> > This specific case is not in that category (i.e. has no
> > user-observable behaviour change), so I think it qualifies for 2.2 -
> > provided there is enough trust in its correctness.
> The "bugfix part" of these changes certainly had user-visible aspects, in
> that before it was possible for objects in older generations to get
> yanked back into younger generations. This can affect when objects get
> collected, and so throw off over-tuned programs slinging gc.enable() and
> disable() "at exactly the best time(s)".
Performance change is not quite the same thing as behavior change.
I agree with Martin that, assuming a performance-oriented change is
'known' to be correct (no change in the inputs-to-outputs behavior
of programs), the criterion should be one of overall benefit rather han
one of Pareto optima.
> > I'm concerned that backporting more changes to Python 2.2 will become
> > difficult in that area, if the GC implementations vary significantly.
> Maintaining multiple branches is always a PITA.
Yes, but the degree of pain varies with the branches' separation.
> > Maybe this can be reconsidered when there actually is another change
> > to backport.
> Anyone who is so inclined is welcome to reconsider it non-stop <wink>.
I suspect we'll indeed reconsider it. Whether we do something about
it after the reconsideration will depend on cost-benefit analysis...