[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