[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Martin Aspeli]

Hi Jens,

> 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.

Right.

> 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.

Cool.

> 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.

Martin