> I accept that argument completely. The question is how quickly can > we make types.py go away, and how do we treat it until then. I > would be disappointed, but not extremely inconvenienced if it went > away totally in 2.3. In spite of that, I feel strongly that the > right thing to do is to maintain types.py consciously. There's no way it can go away completely in 2.3. The PEP rules about deprecation are clear: they require at least a year (i.e. two releases or more) from the announcement of the deprecation; in cases of heavily used modules like types.py I think we should go slower. But a general rule is that no new features should be added to deprecated modules, since they are only kept around so that old code using them doesn't break; new code should not use deprecated modules. > I think we should keep adding to it, because users expect core types > to be in there. So far there has been no counter-argument to this > point *at all*. All of the proposed counter-arguments have really > been addressing the entirely different (and valid) reasons why > types.py should be depricated. OK, so let me explain why I'm against adding new stuff to types.py. I'm against adding new features to anything that's (about to) being deprecated. The addition of new features sends the wrong message: it suggests that the module is in active use, recommended for use, supported, maintained, etc. When someone finds that types.py has no name for the Boolean type, maybe this will cause them to realize that it's being deprecated and that in the long run (with emphasis on long) it's going away. > In the costs of maintaining types.py weren't so insignificant, then > I'd be all for letting it rot. We even have volunteers who are > willing to do the work! So why are we still raining on the parade? See my note explaining that having all types bundled together was not an optimal idea. I don't want to break old code, but I do want to nudge people into the right direction, away from types.py. --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