Tim Peters <tim.one@comcast.net> writes: > All that remains is new optimizations, and those can't be sold as a bugfix. 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". 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. > Large (in the sense of lines of code) changes to gc really need to go thru > lots of testing too. The optimizations involve some new algorithms, not > just tweaking the former ones. I'm concerned that backporting more changes to Python 2.2 will become difficult in that area, if the GC implementations vary significantly. Maybe this can be reconsidered when there actually is another change to backport. Regards, Martin
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