Re: Python (was Re: I did not inhale)

On 27/08/2024 09:39, Richard Kettlewell wrote:

John Ames <commodorejohn@gmail.com> writes:

But even if that helps you organizationally, it doesn't resolve issues
of the interpreter potentially mis-parsing things due to mismatches in
tab/space factor between $EDITOR and the Python RTE, which is a truly
ridiculous thing to have to be concerned about.

 In many years of using Python routinely and extensively I’ve simply
never found the whitespace issues that people are worrying about here to
be a problem in practice. Some of this may be a matter of experience but
if so, it’s a form of experience that must have built up very quickly.
 As an aesthetic objection, of course, there’s no accounting for
taste. But it doesn’t seem to be a practical problem in reality.
 (In contrast C’s rules have occasionally been a practical problem,
contributing to at least one high-profile software vulnerability and
attracting compiler warnings to mitigate the risks.)

These are the problems I've seen. I haven't used the language extensively, but I've used it enough.
(1) An tab at the start of a line gets accidentally indented or unindented. If you weren't paying close attention, it may not be clear that that has happened, if this line was either the last line of an indented block, or the line following
(2) You want to temporarily comment out an 'if' line so that the following block is unconditional. You can't do that with also unindenting the block. And, also  the block then merges with the following one as it's at the same level, so when you want to change it back...
(3) Similarly, you want to temportarily wrap an 'if' statement, for example, around a block of code. But you can't do it witout indenting that block.
(4) Sometimes you want to add temporary debug code as part of a block. Usually I write such lines in all-caps and without indentation to make them stand out clear. With Python, I can't use all-caps and I have to use exactly the same indent as the rest of the block. So the lines merge. Then when I need to remove the code, it's not clearly delimited.
(5) Sometimes you want to temporarily comment out the contents of a block. But Python doesn't allow an empty block; now you have to use 'pass'. And then get rid of if later.
(6) You want to add extra statements to the end of a block, but where IS the end? You have to INFER the ending by looking for a line with a smaller indent. But suppose you're at the bottom of a window; is that bottom line the last in the block, or is there another one at the same indent just out of sight? You have to tentatively keep peeking ahead!
(6a) And maybe there's big comment blocking in the middle of block; comments don't need nesting! If there are lots of comments and few statements, finding the end of the block (ie. the last statement of this block) can become quite an exercise.
(7) You take some Python code you've seen online (eg. in a usenet post) and paste into your editor. Maybe you want to merge it with your own code.
But its tabbing is all spaces; yours is all tabs. Plus invariably, the whole thing has extra indentation (eg. the leftmost statement is already indented). Or you want to copy code from within a block to a different indent level.
The whole thing gets very messy and error prone. You need special editor commands to deal with the mess.
Indented, non-delimited code and data is fine for machine-generated and machine processed code. But it's a disaster for code that has to be human-generated and human-maintained. It's just too fragile.
The fact that people have to resort to adding #end lines, which only partly deals with one or two of those problems, suggest that something is badly wrong.