allow line break at operators

[Seebs]

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

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

Sort of.  Host names are case insensitive, so far as I can tell "always".
Paths past that are distinctly NOT always case insensitive, and since the
server in question happened to be doing what appear to be "straight path
lookups", it mattered a great deal that you had to downcase all but one of
the letters.  (The obvious technique of downcasing them all failed.)

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

Eh, I'm a C programmer, what makes you think I had any vowels to begin with?

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

It does.  I'm not sure whether the errors are compensated for by the
expressiveness.  I *think* on the whole they are, but I am honestly not
sure.  I do like gcc's warning for assignment used as a truth value.

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

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.

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

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

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

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

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

You keep telling me to stop using this editor.  I have not seen a suggested
improvement.  (Hint:  GUI editors are not an improvement for my purposes,
as I do about 99.5% of my editing on machines that aren't in the same state
that I am.  No, the GUI editor cannot offer enough improvement in anything
to justify the cost of copying files back and forth constantly.)

> 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 have really, really, bad ADHD.  When I was a kid a firecracker blew up in
my hand because I *forgot* I was holding it.

I'm not exactly "careless" in the pejorative sense (I don't accept
the implication that it's a character flaw, but I don't think you
intended it either), but functionally, I will make DOZENS of tiny
errors per hour, and yes, I rely on having insurance against them.
I don't really get a vote in this; I can either have insurance
against them, never program at all, or spend a whole bunch of time
trying to figure out what happened.

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

I think that's pretty much the thing.  I regard the "cost" of the insurance
as completely nugatory, and I can identify dozens of times when it's saved
me hours of effort on debugging code, whether mine or someone else's.  And
in general, I am a HUGE fan of things that offer a bit of insurance against
otherwise-minor errors.

If something can make a potentially severe problem into a trivial problem,
that's usually a big attraction to me.

So I think there are a couple of big personal-style questions influencing
this.

1.  Preference for "insurance"-type syntax -- stuff that may not be useful
most of the time but will occasionally prevent failures.
2.  Likelihood of "minor" formatting errors either in your direct work or
in your larger environment (say, people mailing you code, use of web
forum software, etc.)
3.  General preferences for how things are structured.

I strongly prefer explicit matching markers, and by "explicit" I mean *actual
symbols you can see*.  The way in which I view indentation as non-explicit
is as follows:

	if foo:
		if bar:
			baz
	quux

	if foo:
			baz
	quux

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 really don't see why people insist on calling it explicit; it seems
utterly unambiguous to me that it's not.  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".

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