[Python-Dev] PEP 344 (was: with_traceback) (original) (raw)

Guido van Rossum guido at python.org
Sat Mar 3 01:22:18 CET 2007

On 3/2/07, Collin Winter <collinw at gmail.com> wrote:

On 2/26/07, Andrew Dalke <dalke at dalkescientific.com> wrote: > My concern when I saw Guido's keynote was the worry that > people do/might write code like this > > NOENDOFRECORD = ParserError("Cannot find end of record") > > def parserecord(inputfile): > ... > raise NOENDOFRECORD > ... > > > That is, create instances at the top of the module, to be used > later. This code assume that the NOENDOFRECORD > exception instance is never modified. > > If the traceback is added to its traceback attribute then > I see two problems if I were to write code like the above: > > - the traceback stays around "forever" > - the code is no longer thread-safe.

While there are now quite a few threads discussing the problems related to the proposed traceback attribute (thread-safety being the primary one, from what I can tease out), I haven't seen anyone address the rest of PEP 344: the cause and context attributes. Do those who oppose traceback also oppose cause and context? Should PEP 344 be rejected on these grounds, or should we just learn not to pre-instance exceptions if we're interested in these attributes?

Those attributes have exactly the same problems as traceback. They exist mostly to save the butt of those folks who didn't even know they had a problem, so I don't think that saying "if you want this functionality, don't do X" is very helpful.

I'm afraid we're back at square zero; perhaps we should keep the existing (type, value, traceback) API rather than going for radical (and unproven) innovation like "except E as v with tb: ". In the future we will still have the path open to a "Catch" object as proposed by Glyph and Greg; all we'd have to do is give the Catch object sequence semantics during the transition.

I wonder if we should also roll back the new semantics of "except E as v: " of deleting v when exiting ; that was proposed in anticipation of the traceback attribute on exceptions. If we're not doing that, using vanilla variable semantics will give better migration from 2.6 and fewer surprises.

On 3/2/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

They would seem to have the same problems. Whatever solution is adopted for the traceback should probably be applied to them as well, perhaps by generalising the traceback into an "exception context" object that can hold other info.

That would work for the "Catch" object. It wouldn't work so well for the original (t, v, tb) API, nor for the "except E as v with tb" syntax ("except E as v with tb in context for cause" anyone? :-)

The one thing that makes me not want to give up yet is that having the traceback, context, cause etc. as attributes of the exception object would seem to make the API for handling exceptions that much cleaner, compared to having to call sys.exc_info() or even "except E as v with tb".

So, despite the existence of libraries that pre-create exceptions, how bad would it really be if we declared that use unsafe? It wouldn't be hard to add some kind of boobytrap that goes off when pre-created exceptions are raised multiple times. If this had always been the semantics I'm sure nobody would have complained and I doubt that it would have been a common pitfall either (since if it doesn't work, there's no bad code abusing it, and so there are no bad examples that newbies could unwittingly emulate).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list