[Python-Dev] Breaking undocumented API
exarkun at twistedmatrix.com
exarkun at twistedmatrix.com
Mon Nov 8 23:35:53 CET 2010
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
More information about the Python-Dev
mailing list