[Aahz] > >> If a great feature comes up after development starts, too bad -- the > >> next development cycle will usually be less than nine months away. [me] > > Bah. For most features, 9 months is an eternity compared to the time > > it takes to code it. About the only exceptions I recall are new-style > > classes and Unicode; major packages like email or xml also are > > exceptions, but they are usually developed outside the Python CVS tree > > first anyway. [Aahz] > It's not the time for coding that's the issue, it's the time for > testing, documentation, integration, and so on. But even that's > beside the point; this suggestion is being brought up in the context > of the stability/change thread, and this suggestion would IMO go a > long way toward changing perceptions. It depends a lot on the impact of the feature. If something like list comprehensions came up at the last moment, I would agree to put it off. But something like sys._getframe() shouldn't need to wait 9 months, no matter *how* conservative you want to be. I don't think you can give hard and fast rules here. > For example, what's the cost in postponing the bool() change to 2.4? > (I'm not talking about adding the builtin the way you just did for 2.2.1 > (which I agree with), but changing the type of "not x".) > > Note that I'm not pushing this suggestion, but I think your "Bah" is > overstating the opposition. I disagree with your suggestion to put off bool() to 2.4. I see no technical reason to do so, and I don't think politics should influence release decisions to this extent. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4