[IPython-dev] Status of IPython+GUI+Threads+PyOS_InputHook
ellisonbg.net at gmail.com
Sat Feb 7 12:58:32 EST 2009
>> If not, can we implement this ourselves?
> See above ;-).
I don't see where "above" you talk about this. For what it is worth,
here is what I tried:
>>> import readline
>>> import ctypes
<_FuncPtr object at 0x76420>
>>> def my_callback():
... print "In am here"
... return 0
>>> cbf = ctypes.CFUNCTYPE(ctypes.c_int)(my_callback)
<CFunctionType object at 0x769d0>
>>> ctypes.pythonapi.PyOS_InputHook = cbf
If I understand the python source code correctly, readline should now
be calling my callback, but it doesn't seem to. Am I misunderstanding
how this works? It doesn't sound like wx has current support for
PyOS_InputHook, but if we could implement it ourselves using ctypes,
that would solve the problem.
>> work. Has anyone figured this out? Is PyOS_InputHook relevent for
>> non-teminal based IPython frontends?
> It's not relevant at all. Since you control the event loop, there is
> no "input blocking", so the hack that PyOS_InputHook is can be
OK ,at least I am thinking about this correctly. So, if we had GUI
based IPython's only, we would *never* have to worry about this :-)
>> In other words: can we get rid of the messy threading code in
>> IPython?!!! (please say yes)
> Definitely yes, we can (and it's long overdue).
>> 3. SIgnals. I know that one of the most subtle aspect of IPython is
>> getting signals working in the multithreaded shells. How does this
>> change if we move to using PyOS_InputHook rather than our current GUI
> We just have to disable the crash handler, the event loop typically
> deals with ctrl+C itself.
Again, sounds good.
>> 4. There is an IPython commit by Darren Dale saying that the
>> PyOS_InputHook approach wasn't working fully, so it was disabled. Did
>> we get to the bottom of this?
> Wasn't it about pdb?
I hope not.
> Ville M. Vainio
More information about the IPython-dev