On 2011-08-12, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > Seebs wrote: >> You know, that's why the outdents-without-symbols bug me; I have a >> thing with a colon on it introducing something, and then there's nothing >> ending it.
> But there is something ending it: a change in indentation level. Hmm. Okay, here's what I'm not getting. Consider this: if foo: blah if bar: blah blah if baz: blah blah > Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream. What's being pushed into the stream to indicate that the first outdent is two outdents and the second is one? I guess... The parser is explicitly pushing those tokens, but I can't *SEE* those tokens. If I am looking at the end of a really long thing, and I see: blah blah I only know what's happening if I have absolute confidence that the indentation is always by the same amount, etectera. > They're just a change of state in indentation level, which is much more > easily seen without the need for counting braces. Python's parser may need > to count tokens, but for the human reader merely needs to use its intuitive > and highly accurate ability to notice when things line up. Well, that's the thing. In a case like: if foo: if bar: blah blah I notice that *NOTHING* lines up with "if bar:". And that affects me about the way unmatched brackets do. > (Aside: this is why I dislike two-space indents. That's narrow enough to > make the "does this line up" detector subject to too many false positives.) Yeah. >> I want that match so I can let the naive stack-depth-counter >> off somewhere in my brain do its thing without leaving me with a huge >> feeling of unclosed blocks. > Yet another reason to consider brace languages harmful: they spoil the > user's intuitive grasp of intuition as grouping. I assume you mean "indentation as grouping". I'm... not sold on this. It's not that I don't see indentation as a kind of grouping. It's just that I really, really, want groups to have ends. Consider the hypothetical array syntax: a = [ 1, 2 b = [ 3, 4 This *bugs* me. It's perfectly legible, and if you define it that way, it's unambiguous and everything, but... It bugs me. I want beginnings to have an actual corresponding end. > But the human brain is a funny thing: you can train > it to expect to do more work than is necessary, and it will complain when > you make its job easier. Easier varies somewhat from person to person. I need a LOT of parity checks (speaking metaphorically) because my brain is fantastically prone to dropping bits. But I'm really fast. So a thing with lots of parity checks is much easier for me to actually *successfully* use than a thing which omits all that extra stuff. I was overjoyed when I saw that Ruby would let me write 1_048_576. I can read that with fewer errors than I can read 1048576. (And yes, I could also write "1<<20".) -s -- Copyright 2011, 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