Python OS

[Richard Blackwood]

Peter Hansen wrote:

> 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!

Reread what I wrote above Peter, I said _nothing_ about speed.  It says, 
"If....then Python can do X": _can do_ NOT that If.....then Python can 
do X just as well speed wise as C.  It is not writ.

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

Are you so sure of this Peter?  It certainly seems that this might be 
possible but as you point out, if one uses Python for _time critical_ 
interrupts, the code will not live up to the _time critical_ aspect.  
Indeed, I agree and never said otherwise.  I could case less if it is 
extremely slow as speed or even usability was not my aim (I never 
indicated such either and in fact, I indicated otherwise by utilizing 
such terms as _virtual_ and _prototype_  [As Jeremy bravely points out] ).

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

I never said this Peter.

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

Why thank you Peter, that is exactly my aim.