allow line break at operators

[Steven D'Aprano]

Seebs wrote:

> On 2011-08-14, Steven D'Aprano <steve+comp.lang.python at pearwood.info>
> wrote:

>> The way I see it, if something operates by side-effect, then it has no
>> business being treated as an expression.

Which I later withdrew.

> Interesting!  I tend to really like the ability to chain methods,
> depending
> on context.  I find the side-effect/expression mix pretty normal, so I'm
> used to it.

As a rule, chaining method calls risks violating the Law of Demeter. Just
sayin'.


>>> 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.
> 
> If not doing that were a realistic option for me, I'm guessing I'd have
> stopped making typos thirty years ago.

I feel your pain.

But not all typos are equivalent. There are typos in the content of the
document you are editing, and command typos. There's nothing an editor can
do to prevent the first -- how is the editor supposed to know that you
meant "referrer" rather than "referer"? And because it didn't, now we're
stuck with a %*$%@&! spelling error forever.

But a good editor can minimise command typos. User interfaces matter. If
your car required you to reach over your left shoulder and pull a lever in
order to slow down, it would be a really bad design. It would join these
interfaces:

http://www.asktog.com/columns/027InterfacesThatKill.html
http://www.useit.com/alertbox/20050411.html

If your editor doesn't help you minimise bad commands, then your editor
doesn't work for you, it works against you.


>> 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.
> 
> I don't know about "sheer carelessness".  Typos happen.  Typos are not
> something you can prevent from happening just by wanting it very much.

I sympathise, but don't care. That's your problem man, not Python's. Python
has a design philosophy that doesn't match your needs precisely. Oh well,
no language can be all things to all people. If you try, you get Perl, and
you still fail, because your language doesn't meet the needs of people
looking for something that isn't Perl *wink*

I hope you can still be productive in Python, and it's not like anyone
*wants* you to stop using Python and use another language, but you have to
understand that Python wasn't designed for *your* needs precisely. That
doesn't make indentation as syntax a bad choice.


>> 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.
> 
> Ahh, but what about the case where it results in invalid code?  It's not
> necessarily obvious which lines need to be moved after that.

Are you talking about code you've moved from somewhere else and need to
reindent? Then if the code was working before, it will keep working if you
have the same relative indentation. (At least indentation-wise. It may
break due to other factors.) Revert your bad reindent and try again, more
carefully this time.

If you're making semantic changes to the code, not just a simple move, then
surely you understand what changes you're making and not just randomly
indenting and dedenting until it complies? Read the code and decide how to
fix it.

I get it that sometimes there will be code which is hard to follow and hard
to edit. But if that's the case, you've got more maintenance problems than
indentation, and indents are the least of your problems.

 
>>>     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?
> 
> The "end" is misaligned.  Therefore SOMETHING is wrong.  I don't know
> what, but I can be confident that something went wrong.

Okay, now I'm confused... if indentation doesn't matter, how is the end
misaligned? You could write this, and it would still work the same, yes?

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


>> 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.
> 
> The question is not whether it's on the right line.  No amount of
> indenting or
> outdenting can ever break that.  The question is whether I've gotten the
> indentation screwed up.

But if indentation doesn't matter, you can't screw it up. Isn't that the
whole point of this discussion?


[...]
> You keep telling me to stop using this editor.  I have not seen a
> suggested improvement.

There's only one editor worth using. The standard Unix editor, ed.

http://www.gnu.org/fun/jokes/ed.msg.html

*wink*

Your editor is not my problem. But if you're going to come here and tell us
that Python is less than optimal because it doesn't solve the problems you
have with your editor, the obvious answer is that it is not Python's
responsibility to minimise the harm caused when you indent 7 lines instead
of 8, and if your editor encourages you to make mistakes, perhaps you need
another editor.

I have no idea if that editor even exists. Perhaps you need to write it
yourself.



[...]
> The two-tab outdent is either one or two outdents.  I can't point to a
> specific character and say "this is *one* outdent".  So it's not explicit.

"I can point to a specific character" is not what explicit means. The
outdent is defined by a change of indentation level. You had 8 spaces, now
you have 4. That delta is real. Just because the glyph for spaces is
transparent doesn't make it less real, and just because the delta is -4
spaces also doesn't make it less real.

To start a new block in C, I type { and then type } to end it. Explicit. To
start a new block in Python, I type TAB, and then SHIFT-TAB to end it. This
is also explicit.



> I think... I mean, the thing 
> about design philosophy, when you have several design philosophy rules, is
> that NONE of the rules get followed all the time.  I think it'd be much
> more effective to say that one of the other rules won in this case than to
> try to convince people that a variable number of tokens occurring with no
> difference at all in the character stream is "explicit".

The character stream does have a difference.

TAB TAB TAB foo

is different from 

TAB foo

That difference depends on the context, but is usually two dedents.



-- 
Steven