On 2011-08-14, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote:
> Seebs wrote:
>> 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:
>>
>> blah
>> blah
>>
>> I only know what's happening if I have absolute confidence that the
>> indentation is always by the same amount, etectera.
> I believe this is a dubious argument. With only two lines of code in
> isolation, understanding the indentation changes is the least of your
> worries. Adding block delimiters doesn't give you any significant help --
> ESPECIALLY if the block delimiters don't align with the indentation!
> blah
> }
> blah
> }
Interesting. I am sort of getting to an insight into this, which I am not
sure I can articulate.
FWIW, I've had to debug C (well, C++) much worse than that (... long story,
but rest assured, the lulz justified the effort of reading the transcendantly
awful code). I could still do it. :)
> In isolation, you don't even know whether the above is syntactically valid,
> since you have no way of knowing that either end brace is closing an open
> brace or not.
Ahh, but the computer can tell me that. I don't have to see it.
> "Who would write such a horrible mis-aligned piece of code?" Good question.
> If you're going to have style-guides that prohibit writing code like the
> above, then what exactly do the braces give you?
I think what they give me is... basically a parity bit.
It's easy for people to screw up code, such that the code written does not
reflect intent.
Braces give me a likely red flag -- if they are screwed up, I know that this
is a good palce to start looking. If they're not, then all they're costing me
is a little vertical space.
> Yes, yes, if you paste the code into a web forum the indentation may
> disappear, and if your hard drive controller is faulty it may randomly
> overwrite blocks with data belonging to other files. We all agree that
> environments that destroy data are Bad.
"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.
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.
> Do you get worried by books if the last page doesn't include the phrase "The
> End"? These days, many movies include an extra clip following the credits.
> When the clip finishes, and the screen goes dark, how long do you sit
> waiting before you accept that the movie is over?
> *wink*
It's an actual thing I have been bitten by, especially because I often really
enjoy those clips, and I've seen a movie that had two.
> The above example bugs me too, because it is too close to what I'm used to
> in Python. I see an open bracket, I wait for a close bracket. Perhaps this
> would be better:
> a = array
> 1,
> 2,
> b = array
> 3,
> 4,
> Not so bad now, I betcha.
Interesting! For me this triggers the same "WHERE IS THE END MARKER???"
reflex. These bug me like unmatched brackets.
> but you still can't nest arrays. This potential syntax doesn't feel like a
> unified whole, but like a bunch of unrelated fixes for problems. Sometimes
> a literal START and END delimiter is the right answer.
I think so.
> Python's use of indentation to delimit blocks doesn't feel like that. Unlike
> arrays, you can't use blocks in an expression, and I think that's the
> factor which makes all the difference. Ruby folks may call the lack of
> block expressions a problem with Python, but even if they're right, I don't
> think it's a *big* problem.
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.)
> Either way, given the restriction that blocks
> are statements, not expressions, the lack of an overt block markers is not
> a problem for code (with the proviso that a rogue editor doesn't go making
> arbitrary changes to your source code).
Yeah. I suspect that if I'd never used something with braces, I might not
mind as much, but the kinds of errors I've had would probably still be issues.
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.
To some extent, I think I like braces for the same reason I like to use
ECC memory whenever hardware supports it, and I prefer hardware that
supports it. Yes, they're only really useful to me when Something Goes
Wrong (or to accommodate my fussy brain), but something goes wrong often
enough that I derive a lot of benefit from that.
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.
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.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nos...@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.
--
http://mail.python.org/mailman/listinfo/python-list
