"Barry A. Warsaw" wrote: > > >>>>> "MAL" == M <mal@lemburg.com> writes: > > MAL> In general, I think it's a good idea to be very careful about > MAL> introduce flashy new stuff to the std lib since it makes > MAL> backporting fixes harder, e.g. using Python 2.1 features is > MAL> OK, but not 2.2 features (if not absolutely necessary or only > MAL> if they are easily separatable from the rest of the code). > > This is emerging as a common theme, and a good one to adhere to. I > wonder if we should formalize it (i.e. target the stdlib to Python 2.1 > where possible)? Guido van Rossum wrote: > > What would the point be? How many people are moving stdlib modules to > previous releases? I think very few. The point is that in order to not make backporting patches for bug fix releases harder than necessariy, the code should not change in ways which would cause the backport to have to create a variant of the bug fix. This would introduce a branch and most probably new bugs. > I just added True/False to a whole bunch of places, and I'm sure with > each new enticing feature it will be harder to keep the stdlib 2.1 > compatible. True and False are not hard to backport, but any new features which are not replicable in Python 2.1 should not go into the stdlib until we drop support for it. Then, if we do, Python 2.2 should become the new reference and so on. > I'm all for marking certain modules as "have to be backwards > compatible" though -- e.g. sre. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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