Python 3.2 has some deadly infection

[Marko Rauhamaa]

Steven D'Aprano <steve at pearwood.info>:

> But the idea of having standard input and standard output in the first
> place comes about because they are useful for the console.

I doubt that. Classic programs take input and produce output. Standard
input and output are the default input and output. The textbook Pascal
programs started:

   program myprogram(input, output);

> If a system had no command line interface (hence no consoles), why
> would you bother with a *standard* input file and output file that are
> never used?

Because programs are supposed to do useful work. They consume input and
produce output. That concept is older than computers themselves and is
used to define things like computation, algorithm, halting etc.

> On Thu, 05 Jun 2014 14:01:50 +1200, Gregory Ewing wrote:
>> But we were talking about encodings, and whether stdin and stdout
>> should be text or binary by default. Well, one of the design
>> principles behind unix is to make use of plain text wherever
>> possible.

No, one of the design principles behind unix is that all data is bytes:
memory, files, devices, sockets, pathnames. Yes, the
ASCII-is-good-for-everybody assumption has been there since the
beginning, but Python will not be able to hide the fact that there is no
text data (in the Python sense). There are only bytes.

UTF-8 beautifully gives text a second-class citizenship in unix/linux.
It will never be granted first-class citizenship, though.

>> As a result, most unix programs, most of the time, deal with text on
>> stdin and stdout. So, it makes sense for them to be text by default.
>> And wherever there's text, there needs to be an encoding. This is
>> true whether a console is involved or not.
>
> Agreed.

Disagreed strongly.

   tcpdump -s 0 -w - >error.pcap
   tar zxf - <python.tar.gz
   sha1sum <smile.jpg
   base64 -d <a.dat >a.exe
   wget ftp://micorsops.com/something.avi -O - | mplayer -cache 8192 -

Unfortunately, the text/binary dichotomy breaks a beautiful principle in
Python as well. In numerous contexts, any file-like object will be
valid. Now there is no file-like object. Instead, you have
text-file-like objects and binary-file-like objects, which require
special attention since some operate on strings while others operate on
bytes.


Marko