Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

os.read(0,) vs sys.stdin.buffer.read() in python

Tags:

python

stdin

I encountered the picotui library, and was curious to know a bit how it works.

I saw here (line 147) that it uses:

os.read(0,32)

According to Google 0 represents stdin, but also that the accepted answer for reading from stdin is via

sys.stdin.buffer.read()

I was wondering what the difference is between the two. Which is faster? Which is the more portable version?

like image 676
Jay Avatar asked Dec 23 '22 23:12

Jay


1 Answers

Using os.read(0, 32) is an unbuffered read, directly invoking an OS-level syscall and reading only a very specific amount of data (with a firm guarantee that the individual call won't read more than that). Sometimes -- for example, if you're going to be handing off your stdin to a different program and letting it read the rest of the pending data -- you specifically need that.

sys.stdin.buffer.read() is a buffered read (and, without specifying a length, one that reads as much as possible). A buffered read can potentially read more data that you're immediately asking for (even though it only returns the requested amount, keeping the rest in a buffer to use to handle future requests), to reduce the number of syscalls made and thus operate with lower context-switch overhead when reading lots of data (in particular, when you would otherwise be doing lots of short reads, buffering reduces the number of round-trips between userland and the OS kernel).

Which of these is appropriate is deeply dependent on implementation and runtime-envionment details, and a question asking which is appropriate for a given scenario would need to include more details to not be overbroad. What's important is that you don't mix them; performing an unbuffered read after a buffered read can have unpredictable results, since there's no way of knowing how much data was already read by the OS to populate as-yet-unused parts of the read buffer.

like image 137
Charles Duffy Avatar answered Jan 05 '23 17:01

Charles Duffy