Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
Baiju M wrote: I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. I wonder why zope.dottedname isn't being used here either? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: On Thu, Mar 5, 2009 at 11:26 AM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. How to run these kind of big test run now-a-days, any pointer ? 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. Res. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJr9DP+gerLs4ltQ4RAh2FAKCtQApmiKTUPQDWHIIlblpYWfocMQCeI8LP VxJrdbgAlOOWgknn+tGYKE0= =LjBv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Dependency of zope.deprecation in zope.configuration
Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJr2mU+gerLs4ltQ4RAt36AKCjWSU8tgWcLz/ldIOR1bhV+Y1MwgCgwyf6 uT2vXXedLl/YlVNiquIAWJI= =dzwK -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dependency of zope.deprecation in zope.configuration
On Thu, Mar 5, 2009 at 11:26 AM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Baiju M wrote: Hi, zope.deprecation is used in zope.configuration *only* to turn off deprecation warning when accessing attribute of an object in one place. But there is no test case or comment about when such a warning will occur. I have pasted the relevant code here: def resolve(self, dottedname): Resolve a dotted name to an object. try: zope.deprecation.__show__.off() obj = getattr(mod, oname) zope.deprecation.__show__.on() return obj except AttributeError: zope.deprecation.__show__.on() # No such name, maybe it's a module that we still need to import try: return __import__(mname+'.'+oname, *_import_chickens) except ImportError: if sys.exc_info()[2].tb_next is not None: # ImportError was caused deeper raise raise ConfigurationError( ImportError: Module %s has no global %s % (mname, oname)) Can anyone point the reasoning behind turning off deprecation warning there. What kind of deprecation is expected, and why it should not be displayed ? Stephan added that code in revision 29143, four years ago now. He actually added the deprecation framework in that same revision. I would rip it out and see what warnings happen during a big test run: suppressing them doesn't look like a good plan to me. How to run these kind of big test run now-a-days, any pointer ? Thanks, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
