On 2010-11-06, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Thu, 04 Nov 2010 19:37:25 +0000, Tim Harig wrote: >> Examples of communication channels that mangle white space abound.
> Yes. So what? So something which is broken by them is brittle. And in every circumstance *other* than the syntax of Python, specifically, we regard brittleness to common events as a flaw in a design. For instance, Makefiles require tabs to indent rules, and behave strangely if for some reason you use spaces. Many editors, though, can be configured to insert spaces when you hit the tab key. This setup is not intrinsically "broken", it's just a matter of preference. And yet, when used with make, it produces cryptic failures. Everyone, without exception, agrees that this is a flaw in the design of make, and that the "tabs" rule should never have existed. > If your communication channel mangles your data, change > your communication channel, don't expect users of clean communication > channels to hand-enter error-correcting codes (braces) into the data. If you have to hand-enter them, perhaps you should get better tools, as many tools don't require you to hand-enter them. Ahh, but I forgot. You only need to get "better" tools if you're talking about why you *don't* find Python's design to be the one true pinnacle of idealized and perfect engineering. If you're talking about any other language which works fine and is no hassle if you have suitable tools, it is of course ridiculous to suggest that people should need to change away from tools which currently suit them fine. > Why is it the responsibility of the programming language syntax to > correct the problem with Seebs' faulty mail server? It's not. And honestly, if it were just one misconfigured mail server, no one would probably ever start this conversation. But instead it's dozens of mail servers, dozens of web forums, dozens of editors, OCR scanning of printouts, and dozens of other media in which it is easy for small whitespace changes to creep in or appear. All of which were known to exist when the decision was made to design a new file format to be brittle in the face of such changes. > XML is not a data format for human use, it is for use by machines. It is > slow, inefficient, and uneditable by humans except for the most trivial > cases. There are thousands of web pages which have been entered in something which could easily be imagined to be a variant of XML. For that matter, OS X ".plist" files are often stored in XML, which is widely liked because it gives you a nice, robust, human-readable format. Which is amenable to hand-editing if you want to tweak something. XML isn't a *great* format for human use, and it's certainly been aimed much more at use by machines. However, there's a lot to be said for designing machines to use formats which happen also to be easy for humans to read, at the very least, and possibly even easy to write. ("Easy" being, of course a relative term.) -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions. -- http://mail.python.org/mailman/listinfo/python-list