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 ncoghlan
Recipients Jim.Jewett, Trundle, Yury.Selivanov, benjamin.peterson, cvrebert, daniel.urban, eric.araujo, gcbirzan, gvanrossum, jamesh, ncoghlan, pitrou
Date 2013-10-19.14:07:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Actually, I take back the performance comment - Jim's right that in the normal case, the slowdown should be minimal (it's just some additional checks that certain slots aren't populated on each listed exception class), and types can already influence that by messing with the MRO.

That just leaves the complexity argument associated with running arbitrary code at an unexpected place in the eval loop, and for that the tests in the patch would need to be strengthened with some pathological examples like:

- __subclasscheck__ raising an exception
- __subclasscheck__ raising and then suppressing an exception
- __subclasscheck__ invoking the garbage collector
- __subclasscheck__ hitting the recursion limit
- __subclasscheck__ provoking MemoryError

The games the current patch already has to play with the recursion limit also bother me.

However, if an alternate approach could be found that avoids the adjustment of the recursion limit in the eval loop, that also sensibly survived the kinds of arbitrary code execution torture tests I mention above, then I'd be far more sanguine about the idea of actually resolving the discrepancy rather than formalising it as part of the general fact that the exception hierarchy isn't as flexible as most of the rest of the language.
Date User Action Args
2013-10-19 14:07:14ncoghlansetrecipients: + ncoghlan, gvanrossum, jamesh, pitrou, benjamin.peterson, eric.araujo, Trundle, cvrebert, daniel.urban, Yury.Selivanov, Jim.Jewett, gcbirzan
2013-10-19 14:07:14ncoghlansetmessageid: <>
2013-10-19 14:07:14ncoghlanlinkissue12029 messages
2013-10-19 14:07:14ncoghlancreate