[IPython-dev] Kernel-client communication
Thu Sep 9 14:48:59 CDT 2010
On 9 September 2010 16:58, Robert Kern <firstname.lastname@example.org> 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
> > stubborn. Well I'm a bit of a purist at times and I keep to my opinion
> > 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
> > > 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
> > > 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
> > 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
> > the same stream that's used for executing commands. The interpreter just
> > for the next "command", which is then interpreted as text, rather than
> > 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
> we allow a greater flexibility to present different things in different
> 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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev