<br><br><div class="gmail_quote">On 9 September 2010 16:58, Robert Kern <span dir="ltr">&lt;<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>&gt;</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>
&gt; Hi,<br>
&gt;<br>
&gt;  &gt; But thanks for your feedback and ideas: only if we can explain and<br>
&gt;  &gt; clarify our thoughts sufficiently to justify them, can we be sure that<br>
&gt;  &gt; we actually understand what we&#39;re doing.<br>
&gt;<br>
&gt; Hehe, I can imagine you (or others reading this thread) start to think I&#39;m<br>
&gt; stubborn. Well I&#39;m a bit of a purist at times and I keep to my opinion unless<br>
&gt; I&#39;m convinced by good arguments :)  But hey, its your project, so please let me<br>
&gt; know if you&#39;ve had enough of my criticism.<br>
&gt;<br>
&gt; So here&#39;s a little more ...<br>
&gt;<br>
&gt;      &gt; * I really think you can do with less sockets. I believe that the (black)<br>
&gt;      &gt; req/rep pair is not needed. You only seem to use it for when raw_input is<br>
&gt;      &gt; used. But why? When raw_input is used, you can just block and wait for some<br>
&gt;      &gt; stdin (I think that&#39;ll be the execute_request message). This should not be<br>
&gt;      &gt; too hard by replacing sys.stdin with an object that has a readline method<br>
&gt;      &gt; that does this. If two users are present, and one calls raw_input, they can<br>
&gt;      &gt; both provide input (whoever&#39;s first). To indicate this to the *other* user,<br>
&gt;      &gt; however, his prompt should be replaced with an empty string, so his cursor<br>
&gt;      &gt; is positioned right after the &lt;text&gt; in raw_input(&#39;&lt;text&gt;&#39;).<br>
&gt;<br>
&gt;     Keep in mind that the direction of those sockets (the normal xreq/xrep<br>
&gt;     pair for client input and the req/rep for kernel stdin) is opposite,<br>
&gt;     and that&#39;s because they represent fundamentally different operations.<br>
&gt;<br>
&gt;<br>
&gt; I get that, but I&#39;m not sure whether this is correct/necessary for the<br>
&gt; raw_input. In the original Python interpreter, raw_input just reads from stdin,<br>
&gt; the same stream that&#39;s used for executing commands. The interpreter just waits<br>
&gt; for the next &quot;command&quot;, which is then interpreted as text, rather than executing<br>
&gt; 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&#39;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>