allow line break at operators

[Seebs]

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

"Risks violating" isn't the same thing as "violates".

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

Yeah.

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

Life is full of tradeoffs.  The editor does a lot of things which very
much improve my performance, with costs which are usually pretty easily
mitigated.

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

Debatable.  There's a sort of fuzzy boundary between "clearly this is a
defect in the product" (see interfaces that kill), and "clearly this is
a defect in the user".  In fact, one of the major areas of interesting UI
research involves interfaces that accommodate things which are generally
regarded as defects in the user.

Think about colorblindness.  Obviously, it's the user's problem, not the
editor's, but an editor which picks colors which most colorblind people
can't distinguish for something important is going to get castigated for it.

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

I think it depends a lot on the goals.  So far as I can tell, the primary
goal of the policy was to eliminate a class of errors.  It... well, it does
this in a strictly technical sense, in that every error which occurs is no
longer of that class.  It does not seem to me that it's done very much to
turn the kinds of things which used to result in that class of errors into
non-errors; rather, it's turned them into different errors.

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

The point is...

I can't *TELL* what the boundaries of the bad-reindent are.  Because there's
no unambiguous point at which I can say "oh, look, here is the line where
the indentation starts being wrong", unless there's a syntax error... and
even then, the syntax error might be before or after the actual bounds of
the bad indent.

With properly-braced code in a brace language, any mis-indent you do can be
unambiguously identified -- you have a 100% guarantee that you know what
the first and last misindented lines are.  In Python, you can usually guess
within a couple of the lines, more easily if you're familiar with the
code.

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

The case that has historically bitten me is that I move N lines of code, and
then I try to adjust the indentation of those N lines, and... SOMETHING
happens.  Maybe someone somewhere introduced tabs and adding four leading
spaces doesn't do anything.  Maybe I mis-counted N.

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

Not if the only reason that it's hard to follow is that the indentation
is screwed up.

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

Indentation doesn't affect the *compiler*, but we know the rules for
indentation.

It's a parity bit.  If the indentation and the begin/end don't agree, then
I *know something is wrong*.  And I know on exactly which line it becomes
wrong.

That turns out to save me a fair bit of time if I have to look at code and
try to figure out what's wrong.

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

I think there is some confusion because the word "matter" has more than one
meaning.

Indentation does not control what the compiler does in, say, C or Ruby.  It
does matter to the *reader*.

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

Heh.

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

But they're *not problems* -- unless I'm using Python.  The rest of the time
it's just the ordinary thing where sometimes when you're using a computer you
typo, misclick, or whatever.

Hmm.  Lemme try an analogy.  Imagine, if you will, an editor with the helpful
trait that if you close a window it closes, bang, whether or not anything has
been touched in it.  Your argument here is roughly:

	But if you're going to come here and tell us that Hypothetical Edit
	is less than optimal because it doesn't solve the problems you have
	with your mouse, [...]

Which is to say:  Yes, I usually expect software to be designed to handle
common problems gracefully.

Whether this is "Python's problem" or not is really an incoherent question;
all we can do is talk about what the effects are, and it's up to Guido or
whoever else to decide whether they care.  In terms of language adoption,
it has certainly been a "problem" historically; there are many people who
might have used Python but ended up not doing so because the indentation
thing interacted badly with their other requirements.

I tend not to care much about assigning "blame".  I don't care whether a
tool is correctly designed for someone who isn't me, or is incorrectly
designed, because neither matters.  All that matters is whether I can use
it reasonably easily.  With Python, the single barrier I've encountered
to a pleasant and productive programming experience has been the indentation
thing.  Apart from that it's a language I'd basically get along with.

But, for whatever reason, the net result is that programming in Python is
a perpetual exercise in frustration for me.  I still prefer it to a number
of other languages, but it's always annoying; it's like using a stereo
system that has a persistent high-pitched whine, but otherwise has very good
sound.

> "I can point to a specific character" is not what explicit means.

No, but...

An explicit thing is by definition a thing which is *NOT INFERRED*.

If the same sequence of characters can be one or two tokens, depending
on a sequence of characters twenty lines ago, that looks very much like
something is being *inferred*.  Information external to the sequence of
characters currently being tokenized is being used to determine what
tokens to recognize.

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

The character streams I was talking about don't.

Character stream:  tab tab tab "foo" newline tab "bar".  This is, as you
say, *usually* two dedents, but it could be one.  Same exact stream of
bytes, and yet the newline/tab may be either one or two dedents, or four
if you're working on code where someone has been using four-space indents
but someone happened to convert sets of eight spaces to tabs.

> That difference depends on the context,

My point exactly.  Dedents are constructed from a combination of the current
character stream and information about characters that could easily be
hundreds of tokens back.  That means that they are not explicit in the part
of the character stream where they occur, but are implied by the combination
of that stream of characters with the rest of the stream.

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