From: "Guido van Rossum"
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