On Tue, Dec 16, 2008 at 03:45:01PM -0500, Tres Seaver wrote:
Martijn Faassen wrote:
Christian Zagrodnick wrote: [snip]
Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html
Weird. At first glance I do not understand the context of that decision. There was a decision to "avoid deprecation" made by it doesn't seem to be motivated in the discussion:
"- zope.app.component.interfaces then can import ISite from the new place to avoid deprectation."
You're saying, I think, that we should do the same thing as in that discussion to avoid deprecation too. But I cannot find a reason to avoid deprecation in the original discussion. Could you elaborate on your thinking?
I'm hoping to soon go through quite a few packages and deprecate lots of stuff by moving it into other packages to try to tidy up the dependency structure. If there are important arguments against deprecation warnings I'd like to understand the background.
One issue is that adding deprecation messages for importing symbols from the old makes all "downstream" code add ugly BBB warts in order to suppress them when run against multiple versions.
Also consider deprecation messages triggered not by code, but by the use in existing ZODB databases. ISite is often directlyProvided by persistent objects, which makes the ZODB store a fully-qualified interface name. You'd need an evolution script to walk the container tree and force a repickling of every site to prevent the app from spewing deprecation warnings at runtime. Regards, -- http://pov.lt/ -- Zope 3 consulting and development