Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #79406 > unrolled thread
| Started by | Cameron Simpson <cs@zip.com.au> |
|---|---|
| First post | 2014-10-22 10:46 +1100 |
| Last post | 2014-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.
Re: Flush stdin Cameron Simpson <cs@zip.com.au> - 2014-10-22 10:46 +1100
| From | Cameron Simpson <cs@zip.com.au> |
|---|---|
| Date | 2014-10-22 10:46 +1100 |
| Subject | Re: 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.
Back to top | Article view | comp.lang.python
csiph-web