As a followup to what I wrote yesterday about prompt signal handlingin programs , it's worthwhile to pointout a little problem in Python with signal handling.

As I've noted before , Python normally turnsmany signals into exceptions. It turns out that this has an importantconsequence: it delays processing of signals , because Python onlyprocesses signal exceptions in the interpreter, ie when you're runningPython bytecodes.

(Contrary to the documentation, sys.setcheckinterval does not appearto control how often signal handlers are

There is a certain class of program that decides it knows better thanyou about when you should be able to stop its operation. The mostirritating way to do this is to catch ^C (and even ^\); such programswin a modest prize from me, usually awarded with 'kill -9'.

Yes, some operations are dangerous if interrupted half-way through andprograms need to protect themselves against them. Short operations. Itis very rare that a program needs to block signals for very long

A while back, thedailywtf.com ran this entry onC preprocessor abuse. Unfortunately (and in fact as noted in thecomments), this is nothing to the true devotee of turning C into adifferent language.

This preprocessor trail was blazed early on, in the V7 Bourne shell,written by Steve Bourne. The story goes that Bourne didn't really likeC all that much, and instead much preferred Algol. Armed with the newC preprocessor he saw the opportunity to fix this problem and createdwhat