[Python-Dev] Waiting method for file objects

[Guido van Rossum]

> I have been researching the question of how to ask a file descriptor how much
> data it has waiting for the next sequential read, with a view to discovering
> what cross-platform behavior we could count on for a hypothetical `waiting'
> method in Python's built-in file class.

I have a strong -1 on this.

It violates the abstraction of Python file objects as a thin layer on
top of C's stdio.  I don't want to add any new features that can only
be implemented by digging under the hood of stdio.  There is no
standard way to figure out how much data is buffered inside the FILE
struct, so doing any kind of system call on the file descriptor is
insufficient unless the file is opened in unbuffered mode -- not an
attractive option in most applications.

Apart from the stdio buffering issue, apps that really want to do this
can already look under the hood, thereby clearly indicating that they
make more assumptions about the platform than portable Python.

For static files, an app can call os.fstat() itself.  But I think it's
a weakness of the app if it needs to resort to this -- Eric's example
that motivated this desire in him didn't convince me at all.

For sockets, and on Unix for pipes and FIFOs, an app can use the
select module to find out whether data can be read right away.  It
doesn't tell how much data, but that's unnecessary -- at least for
sockets (where this is a very common request), the recv() call will
return short data rather than block for more if at least one byte can
be read.  (For pipes and FIFOs, you can use fstat() or FIONREAD if you
really want -- but why bother?)

--Guido van Rossum (home page: http://www.python.org/~guido/)