> Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form?
> On 2008-12-22 18:48:47 +0100, "Martijn Faassen"
> <faas...@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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -