[Python-Dev] More deprecations

Guido van Rossum guido@python.org
Fri, 26 Apr 2002 15:12:40 -0400


[MAL]
> > > 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.

[GvR]
> > I think that puts the priorities backwards.  If we can't develop the
> > stdlib beyond what's supported by 2.1 we might as well stop
> > developing.

[MAL]
> Huh ? It's not as if Python 2.1 doesn't offer you any
> means to implement whatever is needed in the standard 
> lib. Most things don't require using bleeding edge language
> features which give 2.1/2.2 bug fix champions a hard time.
> 
> Just to clarify:
> I'm talking about Python 2.1 language features here.
> I'm not requesting to stop working on the standard lib, 
> if that's what you're reading.

I understand you perfectly, and I disagree.  If some code in a stdlib
module can be written clearer or more efficiently by using a feature
in 2.2 or 2.3, I don't see why we shouldn't use that feature, *unless*
it's a module that is specifically marked to be exempt (like SRE).

I won't start adding iterators and generators, nested scopes,
new-style classes and so on just to make maintenance harder, but when
writing new code or when revising existing code, we should use the
features that make sense.  Those features were all added because they
improve the language's usability.  Requiring the entire stdlib to be
backwards compatible with 2.1 would be too difficult to do (and it's
too late already).

--Guido van Rossum (home page: http://www.python.org/~guido/)