On Tue, 24 Jan 2017 10:52 pm, BartC wrote:
>> if condition:
>> statement
>> endif
>> statement
>> endif
>>
>> What's this code meant to do? Can't know.
>
> But whatever it does, a language that enforces 'endif' would report an
> error, so requiring further investigation. Without the 'endifs', it
> would look like this:
>
> if condition:
> statement
> statement
>
> Legal python.
Indeed. And 99.99% of the time it is correct Python as well.
I suspect that the use of redundant braces or end delimiters has something
to do with attitudes to risk. Or even, dare I say it, with confidence in
your own programming skill.
If (generic) you are risk adverse, or have low confidence in your ability,
then you might want all the help you can get from the compiler and insist
on having end delimiter for blocks. Think about how rare it is that it will
really matter:
- you're editing an if block;
- and you do something that changes the block structure;
- but you do it wrong;
- and the failure is something which is still syntactically legal;
- but you don't notice;
- and the failure isn't instantly picked up by your tests;
- or you don't have tests which exercise that part of the code.
That's fairly unusually. How often does it happen? If you're a beginner, or
programming while high/drunk/sick/distracted, it might happen a lot. (I've
seen programmers who are seemingly incapable of writing `y = x + 1` without
six syntax errors and two logic errors.) But, I think, the average
half-decent coder should find that this isn't really a problem more than,
oh, once or twice a year. Or less.
By "a problem" I mean either a bug sneaks through into production, or they
find the bug but it takes more than an hour's debugging.
So if you're risk adverse, you're thinking about that wasted hour, or the
possibility of a bug sneaking into production code. (As if they don't
already, B&D compilers or not.)
But if you're more tolerant of risk (at least when it comes to coding), or
have more confidence in your ability, you might think:
- these bugs are rare;
- an hour isn't a long time to spend debugging;
- besides it probably won't be an hour;
- it's more likely to be five minutes with a debugger;
- and what's the worst that can happen? this isn't a nuclear power plant,
we'll fix the bug in the next release.
It's not that we don't see the benefit of those braces or end delimiters.
But we just don't think they're important enough to carry them around all
the time. Most of my `if` blocks are short, say, two or three lines. Adding
an "endif" after the block increases them by 33% or 50%. Multiply by the
hundreds, thousands, perhaps tens of thousands of block statements I'll
ever write or read, and that's a huge overhead for very little benefit.
And the next time I see a piece of code that ends:
end
end
end
end
end
the author is going to get a kickin'.
So for some of us, endif or however you want to spell it, is just noise,
eating up valuable vertical real estate. We recognise that it is
*theoretically* useful, but the *actual* usefulness in practice is so rare
that it really doesn't matter enough to make it worth while.
There's no right or wrong answer here. Once you get past the actual bug
magnets like C with its optional braces problem, and dangling elses, or
equivalent, the choice becomes one of taste.
There's a million brace-style languages out there for those who want them,
and only a handful like Python. Why can't you folks leave Python the way we
want it, instead of insisting it's wrong?
> Presumably you don't like parentheses in function calls for the same
> reasons; you'd prefer 'f a,b,c' rather than 'f(a,b,c)' in case, with
> copy&paste, someone might end up with: 'f(a,b,c),d)'.
No, because f a, b, c is ambigious.
spam(a, b, eggs(c, d), e)
would become in your system:
spam a, b, eggs c, d, e
and there's no way to tell which arguments are passed to eggs().
(Come on Bart, you've been designing languages for decades. You know this.)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
