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