On 19 November 2013 22:24, Walter Dörwald <wal...@livinglogic.de> wrote: > On 15.11.13 00:02, Greg Ewing wrote: > >> Walter Dörwald wrote: >>> >>> Unfortunaty the frame from the decorator shows up in the traceback. >> >> >> Maybe the decorator could remove its own frame from >> the traceback? > > > True, this could be done via either an additional attribute on the frame, or > a special value for frame.f_annotation. > > Would we want to add frame annotations to every function call in the Python > stdlib? Certainly not. So which functions would get annotations and which > ones won't? > > When we have many annotations, doing it with a decorator might be a > performance problem, as each function call goes through another stack level. > > Is there any other way to implement it?
Yep, you make the annotations a mapping and use module based naming as a convention to avoid conflicts: http://bugs.python.org/issue18861#msg202754 However, that issue also goes into why this is definitely a PEP level question - there's a bunch of things that are currently painful that a general frame annotation mechanism could help simplify. The challenge is to do it in a way that doesn't hurt performance in the normal case, that is acceptable to other interpreter implementations, and to show that it actually *does* make it possible to clean up at least the already noted issues: - avoiding inadvertent suppression of the original context when another exception gets replaced or suppressed inside an exception handler - more reliably hiding traceback frames involving the importlib machinery - more reliably reporting the codec involved in an encoding or decoding error (for example, the exception chaining I added for 3.4 can't provide any context for failures in the bz2_codec input validation, because that throws a stateful OSError that the chaining system can't handle, and thus doesn't wrap) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
