[Python-Dev] [Python-checkins] cpython: Close #17828: better handling of codec errors

Nick Coghlan ncoghlan at gmail.com
Tue Nov 19 13:50:39 CET 2013

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.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:

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
- 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)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list