Message68569
| 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? |
|