allow line break at operators

Seebs usenet-nospam at
Sat Aug 13 02:39:32 CEST 2011

On 2011-08-12, Steven D'Aprano <steve+comp.lang.python at> 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.


Okay, here's what I'm not getting.  Consider this:

	if foo:
		if bar:

	if baz:

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


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:

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


>> 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 = [
	b = [

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

Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam at <-- lawsuits, religion, and funny pictures <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

More information about the Python-list mailing list