[Zope-dev] Dependency of zope.deprecation in zope.configuration
Martijn Faassen
faassen at startifact.com
Thu Mar 5 11:27:43 EST 2009
Hi there,
Baiju, much thanks for looking into this. I hope we can indeed get rid
of this code.
I myself have the suspicion that the deprecation system is perhaps a
'false optimum' in most cases. Putting in deprecations tends to be quite
a bit of work (as it's a code change), the warnings weren't always very
instructive in the past, and we haven't done a good job of removing
deprecations over time.
Instead it might be better if we use that energy to provide better
documentation about changes and what to do in plain text. Code might
break where the deprecation system would provide a backwards
compatibility warning, but perhaps that's a faster and easier way to get
people to update their code.
For deprecated import locations I recommend we just put in a backwards
compatibility import (no deprecation system) and use a combination of
documentation and the enhanced test runner which can report about
indirect imports.
Perhaps there are other cases where the deprecation system is of use,
but I myself am quite inclined to see about ripping it out and see what
happens.
Tres Seaver wrote:
[snip]
> The 'compattest' suff which the sprinters added last month would be a
> place to start: it runs the tests for dependency packages using your
> locally modified package.
For more information see here:
http://pypi.python.org/pypi/z3c.recipe.compattest
If you can't get it to work right for you (it's tricky business to get
it set up), or have any other suggestions for improving it, please start
a thread here. I'll get the right people to listen.
Regards,
Martijn
More information about the Zope-Dev
mailing list