19316, "lydia-duncan", "I/O module: assertEOF and atEOF", "2022-02-25T18:02:24Z"
assertEOF is documented, while
atEOF is not.
assertEOF will check if the channel has reached the EOF and will halt if it has not.
atOEF is inherently race-y, which at the time made us wary of exposing it to users, leading to the creation of
Note that C has an equivalent,
feof, which tests the EOF indicator on a
FILE*. Python doesn't have an equivalent, so far as I could tell, but its
read() function after reaching an EOF will always return the empty string, so that result can be used to perform a similar check.
The IO subteam believes that halting if the EOF has not been reached is not useful - it seems like we would want to continue to operate on the channel if we had not reached EOF yet. We propose removing
assertEOF and replacing it with a documented
atEOF that warns users about races. We could also potentially give
atEOF a better name in the process.
This is still open for discussion, we are curious to hear other thoughts