[Python-Dev] More deprecations
Fri, 26 Apr 2002 19:16:38 +0200
"Barry A. Warsaw" wrote:
> >>>>> "MAL" == M <email@example.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
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.
CEO eGenix.com Software GmbH
Company & Consulting: http://www.egenix.com/
Python Software: http://www.egenix.com/files/python/