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 assertEOF.
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