> This is a recipe for disaster. Creating a new function from the old can have > unwanted side effects, since you effectively change the object. For example, > if someone is monkey patching this function, then the deprecation warning > gets lost.
That's a rather extreme use case, and not one that IMO should block the @deprecated decorator from being used. I hope that monkey patching is rare enough that you shouldn't mind checking once a year of so if the thing you're monkey-patching might have been deprecated (in which case you shouldn't be monkey-patching it but instead rewrite your code to avoid it altogether). > In Zope 3's deprecation package, we have decided to put a special deprecation > proxy around the module (instead of the function) and register a list of > attribute names (note that it does not matter whether its a class, function > or other type of object) that are deprecated. The advantage is that you get a > deprecation warning just by looking up the object. Yeah, but not everybody has Zope's proxying machinery. I think you're overreacting. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
