On Mon, Nov 8, 2010 at 13:45, <exar...@twistedmatrix.com> wrote: > On 09:25 pm, br...@python.org wrote: >> >> On Mon, Nov 8, 2010 at 13:03, <exar...@twistedmatrix.com> wrote: >>> >>> On 07:58 pm, br...@python.org wrote: >>>>> >>>>> I don't think a strict don't remove without deprecation policy is >>>>> workable. For example, is trace.rx_blank constant part of the trace >>>>> module API that needs to be preserved indefinitely? I don't even know >>>>> if it is possible to add a deprecation warning to it, but >>>>> CoverageResults._blank_re would certainly be a better place for it. >>>> >>>> The deprecation policy obviously cannot apply to module-level >>>> attributes. >>> >>> I'm not sure why this is. Can you elaborate? >> >> There is no way to directly trigger a DeprecationWarning for an >> attribute. We can still document it, but there is just no way to >> programmatically enforce it. > > What about `deprecatedModuleAttribute` > (<http://twistedmatrix.com/documents/current/api/twisted.python.deprecate.html>) > or zope.deprecation > (<http://docs.zope.org/zope3/Book/deprecation/show.html>) which inspired it?
Just checked the code and it looks like it substitutes the module for some proxy object? To begin that break subclass checks. After that I don't know the ramifications without really digging into the ModuleType code. _______________________________________________ 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