> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4