Python 3.2 has some deadly infection

Steven D'Aprano steve+comp.lang.python at pearwood.info
Wed Jun 4 09:08:50 EDT 2014


On Tue, 03 Jun 2014 15:18:19 +0100, Robin Becker wrote:

> ........
>> The problem is that causal readers like Robin sometimes jump from 'In
>> Python 3, it can be hard to do something one really ought not to do' to
>> 'Binary I/O is hard in Python 3' -- which is is not.
>>
> I'm fairly causal and I did understand that the rant was a bit over the
> top for fairly practical reasons I have always regarded the std streams
> as allowing binary data and always objected to having to open files in
> python with  a 't' or 'b' mode to cope with line ending issues.
> 
> Isn't it a bit old fashioned to think everything is connected to a
> console?

The whole concept of stdin and stdout is based on the idea of having a 
console to read from and write to. Otherwise, what would be the point? 
Classic Mac (pre OS X) had no command line interface nothing, and nothing 
even remotely like stdin and stdout. But once you have a console, stdin, 
stdout, and stderr become useful. And once you have them, then you can 
extend the concept using redirection and pipes. But fundamentally, stdin 
and stdout are about consoles.


> I think the idea that we only give meaning to binary data using
> encodings is a bit limiting. A zip or gif file has structure, but I
> don't think it's reasonable to regard such a file as having an encoding
> in the python unicode sense.

In the Unicode sense? Of course not, that would be silly.

The concept of encodings is bigger than just text, and in that sense zip 
compression is an encoding which encodes non-random data into a different 
format which generally takes up less space.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/



More information about the Python-list mailing list