allow line break at operators

[Steven D'Aprano]

Seebs wrote:

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

Er, most URLs are case insensitive, at least the most common ones, including
HTTP and HTTPS. So I don't quite see why you think this was a 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.

Ys, nd n rdnry nglsh txt, th lss ar chng af vwls cn olsu b e trvl chng.

But try that with your source code :)


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

Yes, print as a statement was a mistake. But assignment as a statement, not
so much. Assignment as an expression in languages that have it tends to be
associated with frequent errors.

The way I see it, if something operates by side-effect, then it has no
business being treated as an expression. I'm not even happy with the usual
convention of Python functions that return None, such as list.sort() -- in
my opinion, languages should have procedures which don't return anything,
and can only be used as a statement, similar to Pascal procedures.

(I'm prepared to make an exception for purely functional languages.)


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

Then don't do that.

I'm not impressed by arguments based on "but if I do something stupid, like
select text with my eyes closed and reindent it without looking, I expect
the compiler to save my bacon". In my opinion, it's not the compiler's job
to protect you from errors caused by sheer carelessness at the keyboard.

In any case, while reindenting an arbitrary set of lines may *possibly*
result in valid code that runs but does the wrong thing, the likelihood of
that happening is remote enough that I'm not going to lose any sleep over
it. There are real-world scenarios involving such semantic errors involving
indentation, but they're pretty rare. I think that six weeks of not having
to type { } or BEGIN END around code blocks has saved far more time and
effort than such errors have cost me in my entire history of Python
programming.


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

How? What makes you so certain that next_thing and something else are
supposed to be inside the loop? They don't even refer to bar. Even if they
did, it's not a foolproof sign, although it is a good hint.

Unless I understand the intent of the code, how can I tell whether the END
token is in the right place or not? And if I understand the intent of the
code, then the END token is redundant.


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

I call that a poor user interface design. If you have to count the number of
lines before applying an edit, instead of selecting a range of text, then
you should stop using a tool that is stuck with a UI from the early 1980s.

Please don't take this as an insult, because it is not meant as one, but it
seems to me from this discussion that you're a more careless coder than I
am[1], and you want more insurance to protect you from your own mistakes.
Braces give you that insurance.

I'm not saying I've never mis-indented a block of code, surely I must have.
But if I did, it was so trivial to fix, and done so rarely, I've forgotten
all about it. Consequently I don't want to pay the cost of that insurance,
as little as it is, because I don't get the benefit of it -- for me, it's
just redundant information that I have to type and read that provides no
real benefit.

And that's why I love Python, because it doesn't make my pay for insurance I
don't need.



[1] For some definition of "careless".


-- 
Steven