MIME-Version: 1.0
In-Reply-To: <871tq0fyun.fsf@elektro.pacujo.net>
References: <CAGGBd_r7tdPc1ZTA380-9aNRnbr6Dm3HzhG2cCH2sJwWn=c5iQ@mail.gmail.com> <mailman.14990.1413777392.18130.python-list@python.org> <87a94rgxi5.fsf@elektro.pacujo.net> <CAGGBd_qsZ=-8sn0YQPT1XQf9Qcn9cJ4Aw=hgR6=at0KzjN3xsg@mail.gmail.com> <mailman.15012.1413845578.18130.python-list@python.org> <87mw8qfhza.fsf@elektro.pacujo.net> <mailman.15019.1413851421.18130.python-list@python.org> <87h9yyf318.fsf@elektro.pacujo.net> <mailman.15049.1413933396.18130.python-list@python.org> <871tq0fyun.fsf@elektro.pacujo.net>
Date: Wed, 22 Oct 2014 17:23:15 +1100
Subject: Re: Flush stdin
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.15055.1413959003.18130.python-list@python.org>
Lines: 34
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!bete-des-vosges.org!feed.ac-versailles.fr!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:79413

On Wed, Oct 22, 2014 at 4:38 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Dan Stromberg <drsalists@gmail.com>:
>
>> On Mon, Oct 20, 2014 at 9:41 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> Nagle affects the communication between the peer OS kernels and isn't
>>> directly related to anything the application does.
>>
>> Actually, Nagle can cause two or more small packets to be merged,
>> which is something an application must be able to deal with, because
>> they could show up in the receiving application as one or more (but
>> anyway: fewer) merged recv()'s.
>
> Packets have barely anything to do with TCP sockets since they provide
> an octet stream abstraction.

TCP does abstract over the individual packets, but they are still important.

>> Of course, but who's doing one byte per second?  You and I in our
>> tests, and perhaps some application developers with remarkably
>> undemanding I/O.  That doesn't really mean we should _recommend_ a
>> series of os.read(0, 1)'s.
>
> No, here's my statement: if you need to process input as soon as it
> becomes available, you can't use sys.stdin. Instead, you need to use
> os.read().
>
> You typically supply os.read() with a buffer of a kilobyte or more. Key
> is, os.read() returns right away if fewer bytes are available.

Then your statement is false. Maybe it's not *efficient* if you always
use sys.stdin.read(1), but you certainly can do it. It's not that you
*need to* use something else.

ChrisA