Richard Blackwood wrote:
P.S. If one can program interrupt routines in C, they can do the same
in Python.
Show me how you set the interrupt jumptables to your routines in
python and
how you write time-critical code which has to be executed in a few
hundred
cpu-cycles. And how good that works together with the GIL.
Here is my logic: If one can do X in C and Python is C-aware (in other
words Python can be exposed to C) then Python can do X via such exposure.
Unfortunately the logic is flawed, even in the case that you
quoted above!
You _cannot_ use Python for a time-critical interrupt, even
when you allow for pure C or assembly code as the bridge
(since Python _cannot_ be used natively for interrupts, of
course), because -- as noted above! -- the interrupt must
execute in a few hundred CPU cycles.
Given that the cost of invoking the Python interpreter on
a bytecode-interrupt routine would be several orders of
magnitude higher, I don't understand why you think it
is possible for it to be as fast.
Of course, if you will allow both assembly/C code here and
there as a bridge, *and* you are willing to accept an operating
system that is arbitrarily slower at certain time-critical
operations (such as responding to mouse activities) than we
are used to now, then certainly Python can be used for such things...
-Peter
