A warning is a warning is a warning, there's no lower level, and
people won't see anything if it isn't in their faces. The usage of
something like a debug error message is unprecedented,
counterintuitive and will not compel anyone to fix their product. We
finally have a _workable_ deprecation policy with accepted ways to
signal deprecation and accepted deprecation periods, I'm against
creating special precedents for no other reason other than to give
anyone, be it Plone users or third party coders or anyone else, a
_false_ sense of security.
We do have precedent in Zope 3 as well as Plone where deprecation
periods were extended because the breakage was unrealistic.
A warning is of course one thing. If getToolByName() is gone entirely in
a year (I don't know if that was your intention or not) it's pretty
scary. Surely, some things deserve longer deprecation periods than
others, and getToolByName() is used in pretty much every third party
product (certainly every one I've written).
The task isn't rocket science, it's just dull work. I know that
because I've spent a long time doing it on that branch. Besides, a
deprecation warning will only show up once for every specific call if
I remember correctly.
That's good - I was going to suggest something like that. :)
Keep in mind that the only tools which will cause the
DeprecationWarning to show are those defined in the CMF package. No
third-party "portal_foobar" tool would cause it.
If you consider the relatively glacial speed of CMF releases you'll
see there's nothing "quick" when the normal policy of removal two
releases down the line is applied. The earliest time getToolByName
could possible go away would be 2.3, and I strongly doubt it will
happen then. We will warn people that it *might* happen, though.
I do appreciate your desire to be conservative, but it's a bit hard
to understand when I hear so many voices from the upper echelon of
Plone developers wanting to completely revamp (for very good reasons)
large parts of it.
I completely agree that this is the right direction and I will certainly
want to use this in my own code and promote it as widely as possible.
I guess I'm a bit wary by some of the experience from Zope 3 (or Zope 2)
where for a time the desire to "tidy" got a bit strong and things were
removed because the policy said so, but which caused a lot of breakage
that wasn't really necessary.
So long as tools remain and remain in content space, getToolByName() can
continue to exist and work (and warn, I guess); it's only a couple of
lines of code, even. The deprecation serves a purpose in terms of
allowing better local overrides and allowing us to eventually move the
tools out of content space. It also helps avoid a dependency on CMFCore
where products were only importing getToolByName() to use tools.
I would argue that removing it wouldn't be better than keeping it in
(with a warning), practically speaking, until tools are removed from
content space, say.
Once again, I think we agree on direction, perhaps disagreeing on speed.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests