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