This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Rhamphoryncus
Recipients Rhamphoryncus, benjamin.peterson, gvanrossum, pitrou
Date 2008-06-22.17:17:33
SpamBayes Score 0.0014784961
Marked as misclassified No
Message-id <aac2c7cb0806221017x6aa94646k64a9c8af48e7072c@mail.gmail.com>
In-reply-to <1214143625.6056.8.camel@fsol>
Content
On Sun, Jun 22, 2008 at 8:07 AM, Antoine Pitrou <report@bugs.python.org> wrote:
> You mean they should be detected when the exception is set? I was afraid
> that it may make exception raising slower. Reporting is not performance
> sensitive in comparison to exception raising.
>
> (the "problem mentioned here" is already avoided in the patch, but the
> detection of other cycles is deferred to exception reporting for the
> reason given above)

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.

>> * PyErr_Display is used by PyErr_Print, and it must end up with no
>> active exception.  Additionally, third party code may depend on this
>> semantic.  Maybe PyErr_DisplayEx?
>
> I was not proposing to change the exception swallowing semantics, just
> to add a return value indicating if any errors had occurred while
> displaying the exception.

Ahh, harmless then, but to what benefit?  Wouldn't the traceback
module be better suited to any possible error reporting?
History
Date User Action Args
2008-06-22 17:17:36Rhamphoryncussetspambayes_score: 0.0014785 -> 0.0014784961
recipients: + Rhamphoryncus, gvanrossum, pitrou, benjamin.peterson
2008-06-22 17:17:35Rhamphoryncuslinkissue3112 messages
2008-06-22 17:17:33Rhamphoryncuscreate