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

On 27/08/2024 12:26, Bart wrote:

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.
>

I have occasionally, but only occasionally, seen problems with white space.  And those would normally be caught by Python 3.

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.

Your problems below are all valid, but not insurmountable.  I too would rather have explicit block delimiters, but it's not actually hard to work with Python as it is.

 (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
 

That /can/ happen.  It is a good idea to avoid mixing tabs and spaces in the same file.  Most editors can be configured one way or the other, but if you use different editors under different circumstances (as I do), mistakes are possible.  They are usually quickly identified and quickly handled.

(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...

Replace your
if cond :
with
if 1 :
or
if True :

 (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.
 

True.  But any editor will let you select the lines and indent them.

(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.

Comments are an extremely easy way to make the code stand out.

 (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.

You can leave the "pass" in, if you don't want to get ride of it later. I sometimes find "pass" to be helpful as an alternative to leaving a hanging indented block.

 (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!

Keep your blocks small and neat.

 (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.

That applies to every programming language (unless you know of one that doesn't support comments).

 (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.

Any sane editor will give you tools to fix that - automatic indentation, tab-to-space and space-to-tab conversion, manual indent or outdent block tools, etc.

 The whole thing gets very messy and error prone. You need special editor commands to deal with the mess.

No, you don't.  (Unless you think "special" means "anything but Windows Notepad" .)

 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.
 

In real-life Python coding, it works fine.  I prefer explicit block delimiters, but I cannot say Python's white-space blocking has been a significant source of trouble or inconvenience for me.  Perhaps that's because I have always been used to careful and consistent formatting.  I don't write C code (or any other code) with inconsistent spacing, mixes of tabs and spaces, or unexpected indentations.  So for me, the spacing and tabbing of Python code would be identical if it had braces or other begin-end markers.

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.
 

No one has to do that.  It's a Lawrence peculiarity, and his coding style (in Python or C, and probably anything else) would be rejected by anyone with a coding standard.  I agree that it suggests that something is badly wrong, but it is not with the language!