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?
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? -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development