[IPython-dev] Kernel-client communication

[Almar Klein]

On 9 September 2010 16:58, Robert Kern <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?

  Almar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100909/a744e504/attachment.html>