[IPython-dev] Kernel-client communication

[Robert Kern]

On 9/9/10 2:48 PM, Almar Klein wrote:
>
>
> On 9 September 2010 16:58, Robert Kern <robert.kern at gmail.com
> <mailto:robert.kern at gmail.com>> wrote:
>
>     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.
>
>
> Fair enough. But what about my second argument: why can commands be executed by
> all clients, but a response to raw_input only from one?

That may be a reason to turn that into an XREQ socket on the kernel and XREP 
socket on the frontends, submitting one XREQ message to each frontend, and 
letting the first response "win", but it doesn't let you reuse the 
kernel-XREP/frontend-XREQ pair of sockets for this purpose.

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