Le dimanche 22 juin 2008 à 17:17 +0000, Adam Olsen a écrit :
> I meant only that trivial cycles should be detected.  However, I
> hadn't read your patch, so I didn't realize you already knew of a way
> to create a non-trivial cycle.
> 
> This has placed a niggling doubt in my mind about chaining the
> exceptions, rather than the tracebacks.  Hrm.

Chaining the tracebacks rather than the exceptions loses important
information: what is the nature of the exception which is the cause or
context of the current exception?

It is improbable to create such a cycle involuntarily, it means you
raise an old exception in replacement of a newer one caused by the
older, which I think is quite contorted. It is also quite easy to avoid
creating the cycle, simply by re-raising outside of any except handler.

> Ahh, harmless then, but to what benefit?

I don't know, I've never used that API, I just proposed returning that
error code since it is computed inside the function anyway.
But let's drop that proposal. Same for PyErr_DisplaySingle if nobody
cares.

> Wouldn't the traceback
> module be better suited to any possible error reporting?

I suppose built-in reporting is needed when reporting a grave error such
as a MemoryError (C code can avoid doing any memory allocations), or an
error that occurred during startup before any pure Python modules could
be initialized (how would you report a syntax error in the traceback
module itself?).

But application code should use the traceback module rather than try to
access the C API.