> > default:
> > fprintf(stderr, "Invalid argument
> to DUP_TOPX: %d!\n", oparg);
[Thomas Wouters]
> Hm, this fprintf is stray debugging code, added because I wasn't
> sure that a SystemError wouldn't crash the interpreter, given that the
> stack is utterly fu*d up at this point and we don't know what the
> compiler thinks is the stack size or block size here. (The snippet
> doesn't show it, but it also raises a SystemError.) Is it okay if I
> remove/comment this fprintf() before 2.0 final ?
Suggest replacing it with:
assert(!"Invalid argument to DUP_TOPX");
Then there's no cost in release mode, but we have a useful check in debug
mode. ("assert(!string)" is a handy C debugging idiom more people should
know about! It's semantically the same as assert(0) (i.e. will fail if ever
reached), but unlike using a comment, using a string gets a useful msg
displayed if it ever does fail).
> (At least it didn't say "awoogah, stray debugging code detected, this
> machine will self-destruct in 10 seconds" :-)
Beats "Unto the root this day a brother is born" <wink -- a famous "can't
happen" msg that, of course, got displayed, many years ago in a different
project -- except the original was in Latin!>.
> Another-day-another-demerit<wink>-ly y'rs,
That's a funny thing about working on Python: collect 5 demerits and you
can exchange them for 1 brownie point! If you're not leaving crap behind,
you're not eating enough Python code.
continuous-recoding-is-as-effective-as-it-is-rare-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4