[Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]

[Roger Ineichen]

Hi Christian
  
> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? 
> [Re:zope.browser?]
> 
> On 2008-12-22 18:48:47 +0100, "Martijn Faassen" 
> <faassen at startifact.com> said:
> 
> > Hi there,
> > 
> > All right, I was getting a bit confused when it appeared you were 
> > arguing against moving things at all, but you're basically 
> in favor of 
> > leaving the old APIs intact without explicitly breaking them.
> > 
> > I think we need to think of some way to signal that the "preferred 
> > import location" of something has changed that doesn't result in 
> > deprecation warnings. It's clear from this discussion that 
> this should 
> > be done upon request, not during runtime. The old import 
> location can 
> > then stay around indefinitely.
> 
> Right. May I remove the deprecation warning then?

Yes, but only after someone implemented another concept for
notify about old import location ;-)

> > I'd like a tool that I can point at a package and it'll 
> sort through 
> > whatever it imports and tell me which ones are not 
> importing from the 
> > "right" public location. Each package should have some way 
> to indicate 
> > to that tool whether certain imports are better made from somewhere 
> > else if one is in the business of reducing dependencies. 
> Perhaps a # 
> > BBB comment is enough, though what it looks like exactly 
> depends a bit 
> > on how the tool will work in the end.
> 
> A correctly crafted BBB together with some simple grep-like 
> tool would be sufficient, would it not?

What is grep ;-)

I don't like that. Probably we should use the existing devmode
or something like that? Devmode whould allow us to use it at
runtime and during testing. What about a deprecation mode?

I really like to use such deprecation messages in production too.
I think it's a must that we can use them on productive servers
and see what happens with things stored the ZODB.

Regrads
Roger Ineichen