[Python-Dev] RE: More informative error messages

[Tim Peters]

[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>.