allow line break at operators

[Seebs]

On 2011-08-14, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> Seebs wrote:
>> 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.

> I believe this is a dubious argument. With only two lines of code in
> isolation, understanding the indentation changes is the least of your
> worries. Adding block delimiters doesn't give you any significant help --
> ESPECIALLY if the block delimiters don't align with the indentation!

>                         blah
>  }
>         blah
>                                 }

Interesting.  I am sort of getting to an insight into this, which I am not
sure I can articulate.

FWIW, I've had to debug C (well, C++) much worse than that (... long story,
but rest assured, the lulz justified the effort of reading the transcendantly
awful code).  I could still do it.  :)

> In isolation, you don't even know whether the above is syntactically valid,
> since you have no way of knowing that either end brace is closing an open
> brace or not. 

Ahh, but the computer can tell me that.  I don't have to see it.

> "Who would write such a horrible mis-aligned piece of code?" Good question.
> If you're going to have style-guides that prohibit writing code like the
> above, then what exactly do the braces give you?

I think what they give me is... basically a parity bit.

It's easy for people to screw up code, such that the code written does not
reflect intent.

Braces give me a likely red flag -- if they are screwed up, I know that this
is a good palce to start looking.  If they're not, then all they're costing me
is a little vertical space.

> Yes, yes, if you paste the code into a web forum the indentation may
> disappear, and if your hard drive controller is faulty it may randomly
> overwrite blocks with data belonging to other files. We all agree that
> environments that destroy data are Bad.

"Destroy data" is a sort of fungible concept.  I was reading a comic book
recently and it contained a URL for a poem which had been parodied.  The
URL had been hand-lettered... in block capitals.  The actual URL had exactly
one upper case letter in it.

Whoops.

In general, I don't think all data-loss is identical in severity.  Outside
of Python and Makefiles, I don't use anything where whitespace damage of
the sort of "losing or changing leading spaces" is usually significant,
so I *normally* regard it as a trivial change.

> Do you get worried by books if the last page doesn't include the phrase "The
> End"? These days, many movies include an extra clip following the credits.
> When the clip finishes, and the screen goes dark, how long do you sit
> waiting before you accept that the movie is over?

> *wink*

It's an actual thing I have been bitten by, especially because I often really
enjoy those clips, and I've seen a movie that had two.

> The above example bugs me too, because it is too close to what I'm used to
> in Python. I see an open bracket, I wait for a close bracket. Perhaps this
> would be better:

> a = array 
>     1, 
>     2,
> b = array 
>     3, 
>     4,

> Not so bad now, I betcha.

Interesting!  For me this triggers the same "WHERE IS THE END MARKER???"
reflex.  These bug me like unmatched brackets.

> but you still can't nest arrays. This potential syntax doesn't feel like a
> unified whole, but like a bunch of unrelated fixes for problems. Sometimes
> a literal START and END delimiter is the right answer.

I think so.

> Python's use of indentation to delimit blocks doesn't feel like that. Unlike
> arrays, you can't use blocks in an expression, and I think that's the
> factor which makes all the difference. Ruby folks may call the lack of
> block expressions a problem with Python, but even if they're right, I don't
> think it's a *big* problem.

I actually really *like* that Ruby and Lua let pretty much everything just
be an expression.  I was utterly dumbfounded when I found out that "print"
in Python is a kind of statement, not a function or something comparable.
(This seems to have changed recentlyish.)

> Either way, given the restriction that blocks
> are statements, not expressions, the lack of an overt block markers is not
> a problem for code (with the proviso that a rogue editor doesn't go making
> arbitrary changes to your source code).

Yeah.  I suspect that if I'd never used something with braces, I might not
mind as much, but the kinds of errors I've had would probably still be issues.

Say I try to indent or outdent something and I grab the wrong set of lines.
It's certainly possible for this to result in valid code... And I have no
cue as to what happened.  Even if I get a warning, I can't necessarily
tell what happened.

To some extent, I think I like braces for the same reason I like to use
ECC memory whenever hardware supports it, and I prefer hardware that
supports it.  Yes, they're only really useful to me when Something Goes
Wrong (or to accommodate my fussy brain), but something goes wrong often
enough that I derive a lot of benefit from that.

Refactoring C or Ruby is easy for me.  Refactoring Python is hard for me.
I really do rely on visible markers to sanity-check the boundaries of what
I'm indenting or outdenting.  If I do something in my editor and end up with:

	foo.each do |bar|
	    bar.do_a_thing
	    do_something_with(bar)
	    end
	next_thing
	something else

I know immediately that it's wrong.

If I do something in my editor and end up with:
	if foo:
	    bar.do_a_thing
	    do_something_with(bar)
	    next_thing
	something else

I can't immediately see that I hit the wrong number key when telling
the editor how many lines to adjust.

Typos happen.  I rely heavily on things that let me catch them in as many
ways as possible.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam at 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.