One of my biggest pet peeve in #python is the open() API. It should not have a "text mode", and it should certainly not be the default.
All files are binary, there is not a "text world" and a "bytes worlds".
Some binary files represent encoded text.
I hate it because it gives people the wrong idea on how things work. I think dart got it right, it separates opening the file and parsing the text inside::
file.openRead().transform(utf8.decoder).transform(new LineSplitter())
I wish we did this for Python. open() would have only read/write/append modes, not "text" or "bytes" non sense, and always produce bytes. But the returned file like object should have a text() method so that you can do:
with open(file).text('utf8') as f:
for l in f:
@bitecode I admire your impulse here, but this would be a usability disaster unless "text open" were the default and "bytes open" were something else.
The reason is that you very rarely actually manipulate files as bytes - you mainly use some sort of abstraction. Almost certainly "put some text in this file" is the most common abstraction people use. "Why do I need to always call the `.text` method every time I open a file?" would be one of the top complaints about the ergonomics of Python.
Not to mention people would probably get confused and start using bytestrings.
@pganssle No you just offer open(foo).as_text(encoding). Not hard. This teaches people the reality of files instead of making them think the lie of a world divided between text and binary files. Text files are binary files. It's like saying the world is made of image files and binary files. It makes no sense. Just ensure the API is convenient for getting text out of those bytes, and stop confusing people: 99% of devs have 0 understanding of how text works and panic on UnicodeDecodeError.
@bitecode Despite the fact that it makes the abstraction of "open a file" less clean, I think it was definitely the right choice.