How coding in Python is bad for you

[BartC]

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