[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4