Dan Sommers <d...@tombstonezero.net> writes: > On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote: > > > […] a poor design decision (a line beginning with U+0020 SPACE is > > semantically different from a line beginning with U+0009 CHARACTER > > TABULATION) can be irrevocable – the syntax can't be changed now, > > without breaking compatibility for countless makefiles out there > > already – and cause endless confusion and wasted effort dealing with > > it. > > When makefile syntax came into being, there were ASCII TAB characters, > with a value of 9, and ASCII SPC characters, with a value of 32 (and > there may not even have been those).
A group of (a particular amount of) U+0020 characters is visually indistinguishable from a U+0009 character, when the default semantics are applied to each. > The former is a "control" character, which has specific semantics > associated with it; the latter is a "printable" character, which is > usually printed and interpreted as itself (although in this particular > case, the printed representation is hard to see on most output > devices). And those specific semantics make the display of those characters easily confused. That is why it's generally a bad idea to use U+0009 in text edited by humans. > This mailing list doesn't seem to mind that lines beginning with ASCII > SPC characters are semantically different from lines beginning with > ASCII LF characters, although many detractors of Python seem unduly > fixated on it. The salient difference being that U+000A LINE FEED is easily visually distinguished from a short sequence of U+0020 SPACE characters. This avoids the confusion, and makes use of both together unproblematic. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
