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
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