Nick Coghlan added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12029> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
