[I followed Greg's suggestion and proposed a "deprecated" decorator.]
Raymond writes: > Decorators like this should preserve information about the underlying > function Of course! The version I posted was intended to illustrate the idea, not to be a clean implementation. A long time ago, I proposed a decorator-maker-decorator (see "Creating Well-Behaved Decorators" in http://www.python.org/moin/PythonDecoratorLibrary), and I still think it's probably a wise approach since it's easy for people to be careless and forget to preserve these sorts of features. Jim Jewett writes: > I agree that it should go in the cookbook, but I think you should > set the category to a DeprecationWarning and give the offending > function's name. I had wondered about that, but wasn't familiar with how people actually use categories. DeprecationWarning certainly sounds right, or is there some reason why I should use a custom subclass of DeprecationWarning? Michael Hudson and Irmen point out: > One difference: I imagine (hope!) the java compiler would complain if > the deprecated function is referenced, whereas the python version only > complains if it is called... True enough. And java doesn't complain at all if the deprecated function is invoked via reflection. It's a fundamental difference in style between the two languages: Python barely even HAS a "compile phase", and Python programs tend to be far more dynamic than Java. -- Michael Chermside _______________________________________________ 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
