[Zope-dev] deprecating the deprecation system?
Dieter Maurer
dieter at handshake.de
Mon Mar 9 10:56:57 EDT 2009
Roger Ineichen wrote at 2009-3-8 14:38 +0100:
> ...
>Can you give an example of a meaningless deprecation
>warning?
A few of the deprecations I have disliked for a long time:
> /home/dieter/Z/Products/Archetypes/__init__.py:15: DeprecationWarning: The module, 'Products.CMFCore.CMFCorePermissions' is a deprecated compatiblity alias for 'Products.CMFCore.permissions'; please use the new module instead.
from Products.CMFCore import CMFCorePermissions
Why should I bother about deprecations in foreign packages
(Archetypes in the case above)?
> /home/dieter/Z/Base/lib/python/Products/CMFCore/utils.py:667: DeprecationWarning: format_stx() will be removed in CMF 1.6. Please use StructuredText.StructuredText.HTML instead.
Why should the short "format_stx" no longer be supported and
instead the monster "StructuredText.StructuredText.HTML" be used?
And here is my favorite:
> /home/dieter/Z/Products/HaufePortalBase/__init__.py:86: DeprecationWarning: The product_name parameter of ToolInit is deprecated and will be ignored in CMF1.6: HaufePortalBase
The "product_name" parameter used to be mandatory -- thus all
calls to "ToolInit" had to use it.
Then, a means was found to derive it automatically
from the context. The developper was so happy that he wanted all
others immediately drop the parameter -- result: several dozens of deprecation
warnings for each start -- in trivial cases, where the automatically
derived information was identical to the explicitly provided....
I called out "what a stupidity"....
--
Dieter
More information about the Zope-Dev
mailing list