@stephanelsmith
On unix port, I'type of sys.stdin is a TextIOWrapper.
This is the correct behavior. However what's missing is that it should have a .buffer attribute to access the underlying binary stream -- this is the CPython-compatible way to do this (see the note at the end of the sys.stdin docs -- https://docs.python.org/3/library/sys.html#sys.stderr ).
Conversely, on ESP32, sys.stdin is a FileIO with sys.stdin.buffer available for use.
Confusingly, despite being named FileIO, this object (on all the embedded ports) is actually a TextIOWrapper-like implementation. It is a text stream, and supports the .buffer attribute to get the underlying binary stream.
I don't know the history, but I'm guessing it's called "FileIO" just to save the additional code size for "TextIOWrapper", but if you look at shared/runtime/sys_stdio_mphal.c you can see it's implemented with is_text set to true.
Why not FileIO which would provide text and buffered versions?
I think the solution is just to provide the buffer attribute on the unix version (in vfs_posix_file.c), which should be do-able using basically the same approach as sys_stdio_mphal.c.
select.poll not working properly with sys.stdin
Binary over sys.stdin question, sys.stdin is type TextIOWrapper, not FileIO?
Data loss in string transfer through sys.stdout.write
Micropython automatically converting stdin carriage returns to newlines?
So you have used Python's "pre built in functions", presumably like this:
file_object = open('filename')
for something in file_object:
some stuff here
This reads the file by invoking an iterator on the file object which happens to return the next line from the file.
You could instead use:
file_object = open('filename')
lines = file_object.readlines()
which reads the lines from the current file position into a list.
Now, sys.stdin is just another file object, which happens to be opened by Python before your program starts. What you do with that file object is up to you, but it is not really any different to any other file object, its just that you don't need an open.
for something in sys.stdin:
some stuff here
will iterate through standard input until end-of-file is reached. And so will this:
lines = sys.stdin.readlines()
Your first question is really about different ways of using a file object.
Second, where is it reading from? It is reading from file descriptor 0 (zero). On Windows it is file handle 0 (zero). File descriptor/handle 0 is connected to the console or tty by default, so in effect it is reading from the keyboard. However it can be redirected, often by a shell (like bash or cmd.exe) using syntax like this:
myprog.py < input_file.txt
That alters file descriptor zero to read a file instead of the keyboard. On UNIX or Linux this uses the underlying call dup2(). Read your shell documentation for more information about redirection (or maybe man dup2 if you are brave).
It is reading from the standard input - and it should be provided by the keyboard in the form of stream data.
It is not required to provide a file, however you can use redirection to use a file as standard input.
In Python, the readlines() method reads the entire stream, and then splits it up at the newline character and creates a list of each line.
lines = sys.stdin.readlines()
The above creates a list called lines, where each element will be a line (as determined by the end of line character).
You can read more about this at the input and output section of the Python tutorial.
If you want to prompt the user for input, use the input() method (in Python 2, use raw_input()):
user_input = input('Please enter something: ')
print('You entered: {}'.format(user_input))