[IPython-dev] Kernel-client communication
Thu Sep 9 09:58:55 CDT 2010
On 9/9/10 5:42 AM, Almar Klein wrote:
> > 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
"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