allow line break at operators

[Steven D'Aprano]

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.

Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.
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.

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

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

And it really is intuitive[1]:

http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html

Historically, nearly all languages with braces pre-date the widespread
adoption of tools that think they can mangle whitespace with impunity. (I
would say that the reasons that the tools are broken is *because*
programmers have trained themselves to think that whitespace doesn't
matter -- ask most writers or artists and they would say *of course*
whitespace matters. The separation between elements is important -- perhaps
not quite as important as the elements themselves, but still important.)
Explicit BEGIN/END tokens exist to make the job of the parser easier, not
that of the programmer. 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.



[1] For some definition of intuition.

-- 
Steven