[Python-Dev] More deprecations (original) (raw)

M.-A. Lemburg mal@lemburg.com
Fri, 26 Apr 2002 19:16:38 +0200

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