homepage

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.
> 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)?
(just a small note: it's exception objects that are chained, not
tracebacks... we never modify tracebacks at any point)
> 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.
> 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).