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

On 22/08/2024 11:02, Lawrence D'Oliveiro wrote:

On Thu, 22 Aug 2024 10:10:18 +0200, David Brown wrote:
 

I am a big fan of clear and consistent layout and indentation, which is
forced on you by Python (and Occam), but I too prefer explicit blocking.
   It's harder to get things wrong with explicit blocking, and you are
never faced with space vs. tab conflicts causing semantic changes to the
code.

 Python prohibits those space/tab inconsistencies.
 

No, it does not.  Python treats tabs (at the start of lines, which is the only relevant point here) as 8 spaces by default.  You can change that with command-line flags if you want.  But it is quite happy with mixtures of tabs and spaces as long as the result after tab-to-space conversion is consistent with Python syntax.
So if you have an editor set to 8-space tabs, you can mix spaces and tabs freely, and Python will treat your code exactly as it appears.  If, as many people do, you have an editor with 4-space tabs then mixing tabs and spaces will risk strange effects.  In some cases, Python can see it as inconsistent indentation.  In other cases, you might get indentation that is valid Python syntax but not what the programmer saw in the editor:
    if cond :
         doThis() # 8 spaces
    doThat() # One tab
An editor that sees the tab as 4 spaces will show a very different picture from Python that treats it as 8 spaces.

Nevertheless, I don’t like the loss of redundancy in the way code
structure is expressed, which is why I like to put in “#end” comments.

I would not recommend that.  But I think it makes sense to add a "return" at the end of functions if they otherwise end in indentations, to give a clear ending to the function definition.  That is vastly better than an "# end" comment because it is checked for Python syntax and correct (or at least plausible) indentation.  If you need an end marker for other blocks, "pass" is your friend - again it is better than a comment.