Python 3.2 has some deadly infection

[Rustom Mody]

On Thursday, June 5, 2014 3:11:34 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano wrote:

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


Pascal is for building pyramids — imposing, breathtaking, static
structures built by armies pushing heavy blocks into place. — Alan Perlis

Lisp is like a ball of mud. Add more and it's still a ball of mud
— it still looks like Lisp. — Guy Steele

There are two fundamental outlooks in computer science —
structuring and universality. And they pull in opposite
directions.

Universality happens when a data-structure can hold everything —
a universal data structure.

Some of the most significant advances in CS come from a universalist vision:

- von Neumann machine storing data+code in memory
- Turing-tape able to store arbitrary turing machines (∴ universal TM)
- Lisp program ≡ Lisp data
- Stream of byte can handle/represent everything in Unix — memory, files,
  devices, sockets, pathnames.

However after the allurement of universality is over, the
realization dawns that we have a mess — Lisp is a 'mud-ball'. At
which point people start needing to make distinctions — code and
data, different data-structures, type-systems etc. IOW imposing
structure on the mud-ball.

Taking a broad view, while structuring trades the power for
order, it is universality that adds significant power.

Python is not as universal as Lisp — it has no homoiconicity.
But it is close enough in that any variable/data-structure can
contain any value.

What Marko  is saying is that by imposing the structuring of
unicode on the outside (Unix) world of text=byte, significant power is lost.

This is also Armin's crib.

How significant that loss is, is yet to be seen…