[Python-Dev] RE: More informative error messages
Tim Peters
tim.one at comcast.net
Wed Oct 8 22:41:35 EDT 2003
[Scott David Daniels]
> setjmp/longjmp are nightmares for compiler writers.
I was one for 15 years, so that won't scare me off <wink>.
> The writers tend to turn off optimizations around them and/or get
> corner cases wrong.
> ...
They do. I would aim for a tiny total number of setjmp and longjmp calls,
inside very simple functions. So, e.g., a routine that wanted to die with
an error wouldn't call longjmp directly, it would call a common utility
function containing the longjmp. The latter function simply wouldn't
return. Optimizations short of interprocedural analysis aren't harmed then
in the calling function, because nothing in *that* is the target, or direct
source, of a non-local goto.
Last I looked, the Perl source seemed to do such a thing in places, and
that's about as widely ported as Python. It struck me with force when I was
looking at Perl's version of an adaptive mergesort last year, and got
jealous of how much shorter and clearer the C code could be when every
stinkin' call didn't have to be followed by an error test-and-branch. The
Python sort code hides most of that syntactically via macros, but the
runtime cost is always there. In real life, not one sort in a million
actually raises an exception, so executing O(N log N) test-branch blocks per
sort has astronomically low bang for the buck. In cases like that (which
are common), it doesn't matter how slow actually raising an exception would
be; it's not even tempting to put the longjmp calls inline.
Whatever, I'll never have time to pursue it, so screw it <wink>.
More information about the Python-Dev
mailing list