Adam Olsen <[EMAIL PROTECTED]> added the comment: On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > 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.
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. _______________________________________ 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
