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

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