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… -- https://mail.python.org/mailman/listinfo/python-list
