After spending more time thinking about the implementation I came to a conclusion that it's not easy to generalize replacement of classes. Yes, with some work it's possible to ensure that old name references a new one. But that's not sufficient. If new class has different interface then user's code will fail.
Library's author could provide a mapping via a dict or by manually implementing methods but that'd be only half of the problem. User's code would still pass "old" objects back to the library. So effectively the library would have to support both old and new making all work meaningless. I think it's possible to design a smart wrapper that behaves as an old class in user's code, but as a new class inside library. E.g. by analyzing traceback.extract_stack. But that is too clever and almost certainly comes with its own bag of flaws. I'm confident that this problem leaves the "obsolete" decorators out of scope of this enhancement. Would anyone be interested in using plain deprecation decorators? They are still quite useful: - Can warn when class is subclassed or class-level attributes are accessed (vs warn inside __init__/__new__) - Much easier to be seen by static analyzers Best Regards, Ilya Kulakov
_______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
