On 24/01/2017 17:07, Steve D'Aprano wrote:
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.
You don't know that. If this has been pasted from elsewhere, you need to
match up the indentation level with the current code.
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.
(I'm in the early stages of implementing a C compiler at the moment. The
test input is a single 750Kloc source file (900Kloc when 400 include
files are taken account of).
If I've accidentally lost a space or tab while messing about with it,
and it's significant, I would rather the compiler reported it! As I'm
not going to spot it by perusing the 15,000 pages of code.)
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.
I don't use Python enough for it to be a problem, yet it /has/ been a
problem. I paste code from elsewhere into my editor; usually the
indentation is a mess of spaces, and usually the whole thing is indented
if the imported from a post here.
But if you now try to manually fix the indentation, invariably there
comes a point where you don't know if a particular line has the new
indentation, or the old. The original structure is temporarily lost.
Possibly permanently; you may have to refer to the original. Or, worse,
you don't realise there is a mistake in the new indentation and the
structure has been subtly altered.
This means that a straightforward tweak to a bit a source code is so
error-prone that you are obliged to use automatic tools to do the job.
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'.
Yes, but for using too much nesting!
Sometimes all these 'ends' are a nuisance, but IMO they are valuable,
especially if they appear like this:
end if
end for
as they give extra information. They can also inject extra vertical
space which can be useful (although your example gives too much).
But they also TELL YOU that you are at the end of a set of blocks! In
Python, the above wouldn't appear at all; if you're lucky, you'll get
one blank line. Whether that signals the end of all five blocks, or
three, or none, depends on what comes next: you have to scroll further
and infer from that which of the blocks have terminated.
(I've mentioned in another thread the movie Monty Python and the Holy
Grail, which doesn't have normal closing credits, just a black screen
being projected. Eventually the audience realise there is nothing more
to see... Just having 'The End' appear wouldn't be as quirky but it
would save some time!)
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?
Nothing's going to happen to Python and its unique block style. I'm just
pointing out some of the flaws.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
