[Python-Dev] Some dull gc stats

[Alex Martelli]

On Tuesday 02 July 2002 21:06, Tim Peters wrote:
> [martin@v.loewis.de]
>
> > 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...


Alex