<br><br><div class="gmail_quote">On 9 September 2010 16:58, Robert Kern <span dir="ltr"><<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On 9/9/10 5:42 AM, Almar Klein wrote:<br>
> Hi,<br>
><br>
>  > But thanks for your feedback and ideas: only if we can explain and<br>
>  > clarify our thoughts sufficiently to justify them, can we be sure that<br>
>  > we actually understand what we're doing.<br>
><br>
> Hehe, I can imagine you (or others reading this thread) start to think I'm<br>
> stubborn. Well I'm a bit of a purist at times and I keep to my opinion unless<br>
> I'm convinced by good arguments :)  But hey, its your project, so please let me<br>
> know if you've had enough of my criticism.<br>
><br>
> So here's a little more ...<br>
><br>
>      > * I really think you can do with less sockets. I believe that the (black)<br>
>      > req/rep pair is not needed. You only seem to use it for when raw_input is<br>
>      > used. But why? When raw_input is used, you can just block and wait for some<br>
>      > stdin (I think that'll be the execute_request message). This should not be<br>
>      > too hard by replacing sys.stdin with an object that has a readline method<br>
>      > that does this. If two users are present, and one calls raw_input, they can<br>
>      > both provide input (whoever's first). To indicate this to the *other* user,<br>
>      > however, his prompt should be replaced with an empty string, so his cursor<br>
>      > is positioned right after the <text> in raw_input('<text>').<br>
><br>
>     Keep in mind that the direction of those sockets (the normal xreq/xrep<br>
>     pair for client input and the req/rep for kernel stdin) is opposite,<br>
>     and that's because they represent fundamentally different operations.<br>
><br>
><br>
> I get that, but I'm not sure whether this is correct/necessary for the<br>
> raw_input. In the original Python interpreter, raw_input just reads from stdin,<br>
> the same stream that's used for executing commands. The interpreter just waits<br>
> for the next "command", which is then interpreted as text, rather than executing<br>
> it. In a shell, this idea works quite well.<br>
<br>
</div></div>Sending a command to the interpreter and sending input to raw_input() are<br>
conceptually two different things. By keeping the interfaces for them separate,<br>
we allow a greater flexibility to present different things in different ways.<br>
Just because the original interpreter implementation conflated them out of<br>
necessity due to the limitations of a terminal environment doesn't mean that is<br>
the best thing to do. That would lock us down to the limitations of the original<br>
implementation.<br></blockquote><div><br>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?<br><br>  Almar<br> </div></div>