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