[Python-Dev] with_traceback

Jean-Paul Calderone exarkun at divmod.com
Thu Mar 1 02:58:24 CET 2007

On Wed, 28 Feb 2007 18:29:11 -0700, Adam Olsen <rhamph at gmail.com> wrote:
>On 2/28/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Adam Olsen wrote:
>> > It sounds like we should always copy the exception given to raise,
>> I don't like that either, for all the reasons that
>> make it infeasible to copy an arbitrary object in a
>> general way.
>Exceptions aren't arbitrary objects though.  The requirement that they
>inherit from BaseException is specifically to create a common
>interface.  Copying would be an extension of that interface.
>I believe calling copy.copy() would be sufficient.

Does copying every exception given to `raise' solve the problem being
discussed here?

Consider the current Python behavior: no copying is performed, most code
instantiates a new exception instance for each raise statement, some code
creates a single exception and re-raises it repeatedly.

And the new behavior?  Every raise statement copies an exception instance,
some code will create a new exception instance for each raise statement,
some code will create a single exception and re-raise it repeatedly.

That doesn't sound like an improvement to me.  Normal code will be more
wasteful.  Code which the author has gone out of his way to tune will be
as wasteful as /average/ code currently is, and more wasteful than tuned
code now is.

Plus you now have the added mental burden of keeping track of which objects
are copies of what (and if you throw in the refcount=1 optimization, then
this burden is increased - was something accidentally relying on copying or
non-copying?  Did a debugger grab a reference to the exception object, thus
changing the programs behavior?  Did a third-party hang on to an exception
for longer than the raising code expected?  etc).


More information about the Python-Dev mailing list