On Thu, Nov 5, 2009 at 6:26 PM, Guido van Rossum <gu...@python.org> wrote:
>> >> I'm against restricting deprecation warnings within the stdlib as part >> of this. I actually want more things cleaned up and possibly >> deprecated. That being said, a deprecation warning just means we will >> remove it One Day - anything being deprecated will need a PEP and >> follow the long path to actual removal. >> >> So, -1 from me ;) >> >> jesse > > Actually, I think Dirkjan has a point. I'm not sure that we need > another moratorium (that's a rather dramatic kind of decision which > should be very rare indeed) but I do agree that deprecations are often > more of a pain than they're worth. > > For example, take the deprecation of the md5 and sha modules in Python > 2.6. They make it a bit of a pain to write code that *cleanly* > supports Python 2.4 (doesn't have hashlib) through 2.6 (warns when > importing md5 instead of hashlib). You can silence the warning, but > that is in itself not particularly clean, and users really hate having > the warnings. > > I have come to the conclusion that there are better ways to > pre-announce that a module is going to disappear instead of > deprecation warnings. > I'm interested in hearing how to handle "pending removals" other than deprecation warnings - I guess I'm against the idea that we shouldn't remove/plan to remove things from the stdlib and signal those intentions to users during the moratorium. The mechanics of that can be something other than deprecation warnings, we can add a line to the current moratorium that puts the nix on deprecation warnings (because yes, Dirkjan is right - they can be a pain) but we should outline the alternative process. jesse _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
