On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> Le dimanche 22 juin 2008 à 19:57 +0000, Adam Olsen a écrit :
>> That's still O(n).  I'm not so easily convinced it's cheap enough.
>
> O(n) when n will almost never be greater than 5 (and very often equal to
> 1 or 2), and when the unit is the cost of a pointer dereference plus the
> cost of a pointer comparison, still sounds cheap. We could bench it
> anyway.

Indeed.

>> And for that matter, I'm not convinced it's correct.  The inner
>> exception's context becomes clobbered when we modify the outer
>> exception's traceback.  The inner's context should reference the
>> traceback as it was at that point.
>
> Yes, I've just thought about that, it's a bit annoying... We have to
> decide what is more annoying: that, or a reference cycle that can delay
> deallocation of stuff attached to an exception (including local
> variables attached to the tracebacks)?

The cycle is only created by broken behaviour.  The more I think about
it, the more I want to fix it (by not reusing the exception).

>> This would all be a lot easier if reraising always created a new
>> exception.
>
> How do you duplicate an instance of an user-defined exception? Using an
> equivalent of copy.deepcopy()? It will probably end up much more
> expensive than the above-mentioned O(n) search.

Passing in e.args is probably sufficient.  All this would need to be
discussed on python-dev (or python-3000?) though.

>> Can you think of a way to skip that only when we can be
>> sure its safe?  Maybe as simple as counting the references to it?
>
> I don't think so, the exception can be referenced in an unknown number
> of local variables (themselves potentially referenced by tracebacks).

Can be, or will be?  Only the most common behaviour needs to be optimized.