On 09:57 pm, brett at python.org wrote: >On Mon, Nov 8, 2010 at 13:45, <exarkun at twistedmatrix.com> wrote: >>On 09:25 pm, brett at python.org wrote: >>> >>>On Mon, Nov 8, 2010 at 13:03, <exarkun at twistedmatrix.com> wrote: >>>> >>>>On 07:58 pm, brett at 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. That could be fixed if ModuleType allowed subclassing. :) For what it's worth, no one has complained about problems caused by `deprecatedModuleAttribute`, but we've only been using it for about two and a half years. Jean-Paul
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