[Python-Dev] deprecating string module?

[Raymond Hettinger]

From: "Guido van Rossum" <guido@python.org>

> Maybe we need a new concept, "silent deprecation"?  We would do we
> could to discourage the use of modules (like types or string) in the
> documentation, maybe even removing their documentation altogether, but
> the interpreter would not issue a warning message.

+100

Last month, I took the bait and went to comp.lang.py with a proposal to
deprecate some builtins. I learned that every builtin (except for input())
has a lot of friends. With each set of flames, I mean comments, I modified
my proposal until it evolved to "psuedo-deprecation".  Amazingly, this
attracted no flames at all.  The net result is that psuedo-deprecation seems
to be acceptable as way of removing cruft and lowering the sum total pool of
working knowledge that a Python programmer has to keep in mind.

Instead of de-documenting obsolete tools, I propose moving their
documentation to a separate section of the docs set aside for cruft.  This
makes it possible to understand exactly what old code was doing.  It makes
sure that the newly dedocumented features don't take on never-documented
assumptions. Putting it in a separate place allows us to document the
rationale for psuedo-deprecation and to suggest alternatives. Collecting it
in one place provides authors with a checklist of things to take out of
their book updates.

On the warning side of the equation, I have two ideas.  While there would
not be warnings kicking out automatically, we could add an option or tool
that developers could use to temporarily flag use of psuedo-deprecated
features.  The second idea, is to move responsibility for obsolesence
warnings to PyChecker.


Raymond Hettinger