Python is a very cross-platform sort of language. That is, it runs on no few platforms including the significant three: Linux, OS X and Windows. As a rule you can run programs unchanged across those platforms (and possibly others). You may have to be the tiniest bit cautious with filepath formats or assumptions about default directories and so on. But I, for example, have a couple of Quixote-based websites which run completely unchanged as Apache-CGI programs on my WinXP laptop and the Redhat-based webspace I rent. I take that so much for granted that I forget just how much of an achievement it is.
There’s a thread on the python-list at the moment in which someone’s asking for a cross-platform equivalent to a signal-based approach to timing-out functions. Now, the alarm signal is a Unix-specific concept: it’s not even supported by some kind of POSIX layer under Windows. So what should Python do to achieve cross-platformability?
- Nothing: recognise that not every system has everything
- Some kind of conditionally-defined trickery within the interpreter loop that checks for some Windows-equivalent event object
A lot of questions of the sort “Can’t X be included in Python / the stdlib?” can be answered “Get an implementation in PyPI, see what the uptake is, and come back later”. This kind of thing, though, is more finicky because to be truly effective it needs the cooperation of the interpreter’s internals. Certainly you can fossick around with timeout threads and so on but then, as the saying goes, you have two problems. Obviously nothing’s going to happen here: signal-handling under Unix comes effectively for free; anything else would require an unconscionable amount of mucking with the interpreter which isn’t going to happen.
But I wonder whether something like Windows’ cross-process events which come for free under Windows and, as far as I know, don’t exist under Unix, would have been built-in if the boot had been on the other foot.