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 | amaury.forgeotdarc |
|---|---|
| Recipients | amaury.forgeotdarc, theller |
| Date | 2008年04月05日.00:34:22 |
| SpamBayes Score | 0.039382964 |
| Marked as misclassified | No |
| Message-id | <1207355665.67.0.0182416277925.issue2548@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
Analysis: the primary recursion error is correctly raised, but then there is a call to PyErr_NormalizeException, which calls PyEval_CallObject, which increases the stack depth and hit the recursion limit again... python2.5 don't have the problem because PyEval_CallObject did not check the recursion limit. Different solutions I can think of: - use a prebuilt exception: not possible if we still want an error message containing the context. - in PyErr_NormalizeException, "PyEval_CallObject" is too generic. We could have a special path for exception types deriving from BaseException: directly call the constructor. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月05日 00:34:26 | amaury.forgeotdarc | set | spambayes_score: 0.039383 -> 0.039382964 recipients: + amaury.forgeotdarc, theller |
| 2008年04月05日 00:34:25 | amaury.forgeotdarc | set | spambayes_score: 0.039383 -> 0.039383 messageid: <1207355665.67.0.0182416277925.issue2548@psf.upfronthosting.co.za> |
| 2008年04月05日 00:34:24 | amaury.forgeotdarc | link | issue2548 messages |
| 2008年04月05日 00:34:23 | amaury.forgeotdarc | create | |