[Python-Dev] deprecating string module?

[Alex Martelli]

On Wednesday 29 May 2002 03:58 pm, Guido van Rossum wrote:
> > I'm absolutely against depreceating the string module!
	...
> Or maybe we could introduce a new warning category,
> SilentDeprecationWarning, which is normally ignored (like
> OverflowWarning already is).  This could be turned on explicitly with
> a -W option so someone wanting to check that their code is
> future-proof would have an easy way to do so.
>
> I do not want to ignore all DeprecationWarning messages by default, as
> it would defeat the main purpose of the warning.

This answers ALL the negatives I had just made in my pessimistic
last message and gives me hope in the future again...!

*YES!!!*  Let's have "silent" deprecation warnings, disabled by default,
for features that are _eventually_ going to go away "but not just yet",
at the same time as their goner status gets in the docs and for at
least (whatever number of releases or duration of time) before moving
to "real" (noisy) deprecation.  Features might be instantly put in "real"
deprecation mode like today, when warranted, but a new and even more
gradual option would be allowed for features whose eventual removal
needs to be handled ever so slowly and gradually.  Super!  Why, it might
even let <> go away some day...

I think it should be ensured that (e.g.) a make test with -W gives no
warnings -- basically, that the standard library itself uses no features
that are deprecated even silently (though it may of course _provide_
some).  Otherwise, users would be discouraged from using -W if 
that could given them warnings "from the library itself" that are not
easily removed by working just on their own code.  This needs more
thought if we also want the silently-deprecated features to keep being
tested by the standard test suite at least optionally.


Alex