Antoine Pitrou <[EMAIL PROTECTED]> 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. > 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). _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3112> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com