[IPython-dev] Kernel-client communication
Robert Kern
robert.kern at gmail.com
Thu Sep 9 10:58:55 EDT 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