Larry Hastings added the comment: I'm not surprised it was discussed to death long ago. And I can get behind wontfix. But let me just say that
a) I think an uncrashable Python interpreter is a laudable goal, and steps we can take towards that should not be dismissed out of hand. b) I doubt a range check would "kill" the performance of the _FAST operands. It'd be one lookup/compare/branch each, and the branch predictor would always guess correctly. But I admit I have not tested it. c) Anyway we needn't do it at runtime. We could just as easily scan over the opcodes in the code object constructor and do the range checking there. If we only did the check when the constructor was called directly from Python, it should have no measurable performance impact, only a maintenance cost. d) I expect all these points were brought up in the original discussion. I'd like to read that--but I can't find it. Any pointers would be appreciated. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17190> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
