[Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Tue Nov 19 13:50:39 CET 2013
- Previous message: [Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors
- Next message: [Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 19 November 2013 22:24, Walter Dörwald <walter at 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.fannotation. 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 | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors
- Next message: [Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]