> At some time, there were only string exceptions. Then, instance > exceptions were added, some releases later they were considered the > better choice, so the standard library was converted to use them. > Still, there is no sign whatsoever that anybody plans to deprecate > string exceptions. Now there is: I hereby state that I officially deprecate string exceptions. Py3K won't support them, and it *may* even require that all exception classes are derived from Exception. > I believe the string module will get less importance over > time. Comparing it with string exception, that may be well 5 years. > It seems there are two ways of "deprecation": a loud "we will remove > that, change your code", and a silent "strings have methods" > (i.e. don't mention the module when educating people). The latter > approach requires educators to agree that the module is > "uninteresting", and people to really not use once they find out it > exists. Exactly. This is what I hope will happen. I certainly hope that Mark Lutz has already started teaching string methods! > I think deprecation should be only attempted once there is a clear > sign that people don't use it massively for new code anymore. Right. So now we're on the first step: get the word out! > Removal should only occur if keeping the module [is] less pain than > maintaining it. Exactly. Guess where the string module falls today. :-) --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