Serhiy Storchaka added the comment:
What to do with comprehensions and classes? Corresponding code objects are not
easily accessible and they do not have corresponding function. It would be
difficult to use the locals of the frame with comprehensions.
Maybe use per-module registries of
Changes by Mark Lawrence breamore...@yahoo.co.uk:
--
nosy: -BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1705520
___
___
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +Julian
stage: test needed - needs patch
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1705520
Changes by Dave Malcolm dmalc...@redhat.com:
--
nosy: +dmalcolm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1705520
___
___
Python-bugs-list
Michael Foord mich...@voidspace.org.uk added the comment:
So from the stackframe you can only get to the code object not to the function
object and although the code object is also reachable from a decorator it isn't
mutable so we can't mark it in any way. We could in theory 're-build' the
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Maybe a global registry... implemented with a WeakKeyDictionary?
--
nosy: +amaury.forgeotdarc
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1705520
Michael Foord mich...@voidspace.org.uk added the comment:
Global registry of code objects, hmmm... Could work. I'll prototype it and test
it with IronPython / Jython / pypy.
--
___
Python tracker rep...@bugs.python.org
Michael Foord mich...@voidspace.org.uk added the comment:
__unittest needs to die (with appropriate deprecation).
I agree that a nicer API for marking functions and methods as needing to be
excluded from unittest stacktraces would be useful. A decorator is a good way
to expose that API to
