Re: [Zope-dev] Re: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
[Tim Peters] >> Note: sometimes _internals_ use deprecated gimmicks in order to >> support deprecated gimmicks too, and then stacklevel=3 is too small. >> It's happened so rarely in ZODB that I haven't tried to "do something" >> about that yet. [Chris Withers] > Interestingly, I've found that even this is sometimes not enough, since > you don't know whether you want the caller, the caller's caller or > further up the chain than that. I haven't seen much of that. One place I did is in deprecating subtransactions, where many paths thru the ZODB code have to pass on the original "is this a sub or a 'real' transaction?" flag. In those cases, the relevant methods also grew an optional `deprecation_wng` argument defaulting to True, and _internal_ calls to such methods explicitly pass "deprecation_wng=False". > Is there any way to get the warnings stuff to actually emit a traceback > so it can be followed? No; the `warnings` module doesn't even import the `traceback` module, let alone use it. You can print a traceback yourself by using the `traceback` module, and if you're determined enough you could replace warnings.showwarning() with a function of your own (see the docs for warnings.showwarning, and possible for traceback.print_stack). ___ 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] Re: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
Tim Peters wrote: Note: sometimes _internals_ use deprecated gimmicks in order to support deprecated gimmicks too, and then stacklevel=3 is too small. It's happened so rarely in ZODB that I haven't tried to "do something" about that yet. Interestingly, I've found that even this is sometimes not enough, since you don't know whether you want the caller, the caller's caller or further up the chain than that. Is there any way to get the warnings stuff to actually emit a traceback so it can be followed? cheers, 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] Re: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
[Tres Seaver -- I think; I'm missing context for this email]
> Note that I have just figured out that we can make DeprecationWarnings
> more useful by passing the 'stacklevel' argument to 'warnings.warn';
> passing a value of 2 for that argument causes the warning to be reported
> against the *caller* of the code issuing the warning, which makes it
> possible to find and remove the deprecated use.
I can recommend the approach I use in ZODB. There's a utility module
in ZODB, containing (among other things) functions like this one:
"""
# Raise DeprecationWarning, noting that the deprecated thing will go
# away in ZODB 3.6. Point to the caller of our caller (i.e., at the
# code using the deprecated thing).
def deprecated36(msg):
warnings.warn("This will be removed in ZODB 3.6:\n%s" % msg,
DeprecationWarning, stacklevel=3)
"""
So every gimmick that's going to go away in ZODB 3.6 imports
`deprecated36` from the utility module, and calls it with an
appropriate message. As an intended bonus, when I release ZODB 3.6 I
can just grep for "deprecated36" to _find_ the code that's supposed to
go away (I also annotate tests and docs that should go away with
"deprecated36"). Using a common function also ensures that every
deprecation warning starts with the same string (identifying the
release in which the thing will go away).
Note: sometimes _internals_ use deprecated gimmicks in order to
support deprecated gimmicks too, and then stacklevel=3 is too small.
It's happened so rarely in ZODB that I haven't tried to "do something"
about that yet.
___
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] Re: [Zope-CMF] Better DeprecationWarnings (was Re: SVN: CMF/trunk/CMFDefault/Portal.py - reverted Portal.py change of r39125 to fix BBB temporarily)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Tres Seaver wrote: > >> Note that I have just figured out that we can make DeprecationWarnings >> more useful by passing the 'stacklevel' argument to 'warnings.warn'; >> passing a value of 2 for that argument causes the warning to be reported >> against the *caller* of the code issuing the warning, which makes it >> possible to find and remove the deprecated use. > > > Oooh, coool. Reckon it'd be a good idea if I changed all the deprecation > warnings in Zope to do the same? +10. > I've always found them totally useless 'cos they don't tell you where > they come from and so you can't fix them... > > Bit like the random ZODB errors when it no longer has the class for some > long-forgotten object burried deep in an opaque pickled data structure > which you have no hope of ever finding and deleting... but I digress ;-) Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDV7I2+gerLs4ltQ4RAiTPAJ9ARNJ9C33+BrFMfD7bIgoMNSryQACgtGc5 nzgXeHE9NTZ79BQ5dF9rkN8= =B+U3 -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 )
