[Python-Dev] More deprecations (original) (raw)
Guido van Rossum guido@python.org
Fri, 26 Apr 2002 15:12:40 -0400
- Previous message: [Python-Dev] More deprecations
- Next message: [Python-Dev] More deprecations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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/)
- Previous message: [Python-Dev] More deprecations
- Next message: [Python-Dev] More deprecations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]