[issue36865] FileInput does not allow 'rt' mode, but all its existing delegates do

[Nathaniel Gaertner]

Nathaniel Gaertner <natgaertner at gmail.com> added the comment:

Hey sorry for the delay in responding.

My thought with forcing 'rt' mode is that it would actually reduce the flexibility of the FileInput class. For 5758, I suspect the issue arose out of a confusion about what strings meant in python 2 vs 3. If I understand correctly, a "string" in 2 is actually an array of binary data, displayed as if it were ASCII encoded text. So when it prints the binary data from the gzip file in the example given on that issue, it's happy to say "aha this is ASCII encoded text, let's print it like a string." This leads to the case where 2 "works" (does not mark the printed data from gzip explicitly as binary).

But in 3 strings and binary arrays are totally different kinds of objects! I am unfamiliar with the history of introducing 'rt', but I'm guessing it has to do with disambiguating 'r', since text is now stored in its own unique object type and goes through an explicit encoding process to get there. With the explicit 'rt' and 'rb' modes, 'r' becomes explicitly ambiguous (an oxymoron I know), so if a user provides 'r' they are expressing no preference between text and binary. If they have a preference 'rt' and 'rb' give them the ability to express it.

I may be totally on the wrong track here, or missing some important backward compatibility issues, but that's my thoughts. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36865>
_______________________________________