Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #79406 > unrolled thread

Re: Flush stdin

Started byCameron Simpson <cs@zip.com.au>
First post2014-10-22 10:46 +1100
Last post2014-10-22 10:46 +1100
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Flush stdin Cameron Simpson <cs@zip.com.au> - 2014-10-22 10:46 +1100

#79406 — Re: Flush stdin

FromCameron Simpson <cs@zip.com.au>
Date2014-10-22 10:46 +1100
SubjectRe: Flush stdin
Message-ID<mailman.15052.1413936371.18130.python-list@python.org>
On 21Oct2014 16:16, Dan Stromberg <drsalists@gmail.com> wrote:
[...snip...]
>>> This is tremendously inefficient.  It demands a context switch for
>>> every character.
>>
>> Inefficiency isn't an issue when you generate one byte a second.
>
>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.

Indeed not. But there is one glaring exception: the shell's read builtin.  
Because it can be interspersed in a script between other input-consuming 
commands, it _must_ read no more than one line, and therefore is has to read in 
increments of 1 character.

Of course, that says nothing about the upstream write() granularity.

I now return y'all to your regularly sheduled nit picking.

Cheers,
Cameron Simpson <cs@zip.com.au>

If it ain't broken, keep playing with it.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web