[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    [Python-Dev] More deprecations
From:       guido () python ! org (Guido van Rossum)
Date:       2002-04-26 19:12:40
Message-ID: 200204261912.g3QJCen04912 () pcp742651pcs ! reston01 ! va ! comcast ! net
[Download RAW message or body]

[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/)



[prev in list] [next in list] [prev in thread] [next in thread]