[IPython-dev] Kernel-client communication

Robert Kern robert.kern@gmail....
Thu Sep 9 09:58:55 CDT 2010


On 9/9/10 5:42 AM, Almar Klein wrote:
> Hi,
>
>  > But thanks for your feedback and ideas: only if we can explain and
>  > clarify our thoughts sufficiently to justify them, can we be sure that
>  > we actually understand what we're doing.
>
> Hehe, I can imagine you (or others reading this thread) start to think I'm
> stubborn. Well I'm a bit of a purist at times and I keep to my opinion unless
> I'm convinced by good arguments :)  But hey, its your project, so please let me
> know if you've had enough of my criticism.
>
> So here's a little more ...
>
>      > * I really think you can do with less sockets. I believe that the (black)
>      > req/rep pair is not needed. You only seem to use it for when raw_input is
>      > used. But why? When raw_input is used, you can just block and wait for some
>      > stdin (I think that'll be the execute_request message). This should not be
>      > too hard by replacing sys.stdin with an object that has a readline method
>      > that does this. If two users are present, and one calls raw_input, they can
>      > both provide input (whoever's first). To indicate this to the *other* user,
>      > however, his prompt should be replaced with an empty string, so his cursor
>      > is positioned right after the <text> in raw_input('<text>').
>
>     Keep in mind that the direction of those sockets (the normal xreq/xrep
>     pair for client input and the req/rep for kernel stdin) is opposite,
>     and that's because they represent fundamentally different operations.
>
>
> I get that, but I'm not sure whether this is correct/necessary for the
> raw_input. In the original Python interpreter, raw_input just reads from stdin,
> the same stream that's used for executing commands. The interpreter just waits
> for the next "command", which is then interpreted as text, rather than executing
> it. In a shell, this idea works quite well.

Sending a command to the interpreter and sending input to raw_input() are 
conceptually two different things. By keeping the interfaces for them separate, 
we allow a greater flexibility to present different things in different ways. 
Just because the original interpreter implementation conflated them out of 
necessity due to the limitations of a terminal environment doesn't mean that is 
the best thing to do. That would lock us down to the limitations of the original 
implementation.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



More information about the IPython-dev mailing list