On 09:57 pm, br...@python.org wrote:
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.
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
_______________________________________________
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
