allow line break at operators
usenet-nospam at seebs.net
Sat Aug 13 02:39:32 CEST 2011
On 2011-08-12, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
> Seebs wrote:
>> You know, that's why the outdents-without-symbols bug me; I have a
>> thing with a colon on it introducing something, and then there's nothing
>> ending it.
> But there is something ending it: a change in indentation level.
Okay, here's what I'm not getting. Consider this:
> Python's parser explicitly pushes INDENT and OUTDENT tokens into the stream.
What's being pushed into the stream to indicate that the first outdent
is two outdents and the second is one?
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:
I only know what's happening if I have absolute confidence that the
indentation is always by the same amount, etectera.
> They're just a change of state in indentation level, which is much more
> easily seen without the need for counting braces. Python's parser may need
> to count tokens, but for the human reader merely needs to use its intuitive
> and highly accurate ability to notice when things line up.
Well, that's the thing.
In a case like:
I notice that *NOTHING* lines up with "if bar:". And that affects me
about the way unmatched brackets do.
> (Aside: this is why I dislike two-space indents. That's narrow enough to
> make the "does this line up" detector subject to too many false positives.)
>> I want that match so I can let the naive stack-depth-counter
>> off somewhere in my brain do its thing without leaving me with a huge
>> feeling of unclosed blocks.
> Yet another reason to consider brace languages harmful: they spoil the
> user's intuitive grasp of intuition as grouping.
I assume you mean "indentation as grouping".
I'm... not sold on this. It's not that I don't see indentation as a kind
of grouping. It's just that I really, really, want groups to have ends.
Consider the hypothetical array syntax:
a = [
b = [
This *bugs* me. It's perfectly legible, and if you define it that way, it's
unambiguous and everything, but... It bugs me. I want beginnings to have
an actual corresponding end.
> But the human brain is a funny thing: you can train
> it to expect to do more work than is necessary, and it will complain when
> you make its job easier.
Easier varies somewhat from person to person. I need a LOT of parity checks
(speaking metaphorically) because my brain is fantastically prone to dropping
bits. But I'm really fast. So a thing with lots of parity checks is much
easier for me to actually *successfully* use than a thing which omits all
that extra stuff.
I was overjoyed when I saw that Ruby would let me write 1_048_576. I can
read that with fewer errors than I can read 1048576. (And yes, I could
also write "1<<20".)
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.
More information about the Python-list