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

On 30/08/2024 01:03, Lawrence D'Oliveiro wrote:

On Thu, 29 Aug 2024 14:01:05 +0200, David Brown wrote:
 

On 29/08/2024 02:23, Keith Thompson wrote:

>
Lawrence D'Oliveiro <ldo@nz.invalid> writes:

>
On Wed, 28 Aug 2024 13:29:18 -0700, Keith Thompson wrote:

>
But ok, I found your post and removed all the #end comments.  I found
it just as readable without them as with them.

>
You know what? You are right. That example was just too
well-structured.

>
So why not try to write /all/ your code in a well-structured manner, so
that you don't feel the need to add these "#end" comments?

 Because not all examples can be made that neat, as I demonstrated.

Your example could easily have been written in a more structured manner than you did.  Keith and I both demonstrated that.  (And when you remove the useless stuff from your function, it's even simpler.)
I agree that not /all/ code can easily be written in a neat, well-structured manner - and that occasionally breaking your normal coding convention rules can bring out patterns in the code that make it easier to understand, and easier to write correctly.  But the solid majority of code /can/ be written in a well-structured manner, for most languages.

 

      def register_additional_standard(self, managed_objects) :
          """
          registers additional standard interfaces that are not
          automatically installed at Connection creation time. Currently
          the only one is the object-manager interface, registered with
>
          «conn».register_additional_standard(managed_objects = True)
          """

 Note that Python’s indentation rules don’t apply to multiline string
literals -- don’t you wish they did? So you end up with all that extra
space within the literal. Do you see why I prefer to avoid that?

No - or at least, it is very hard to comprehend why you might prefer the mess you gave.  It is correct that Python multiline strings include any indentation in the strings.  There are three possibilities here - sometimes you want the indents (and thus include them), sometimes you don't want them (and thus you align them at the left of the text), and sometimes you don't care (and thus put them wherever seems neatest). Most function docstrings fall into that third category, since they are mostly used as comments in the code and for the "help" command which ignores the leading indents.
It is probably most common to have multiline docstrings at the left of the file.  I have never before seen a silly mess with manual \n line breaks and line continuation characters, and I hope never to see it again.

 

Line continuation characters in Python are usually an indicator of poor
formatting, or an unhealthy obsession with line length limits.

 I like to keep within a line length limit of about 100 characters.
 

That's a reasonable limit, but does not change my observation.

I don't know if I am more experienced than you in Python (I may have
been using Python for longer, but you may have worked with it more), but
I would say that the "#end" comments directly detract from readability.

 Think about why you bother to indent code in languages where the compiler
ignores such indentation anyway: it means you are expressing the structure
of code in two different ways, one via statement brackets, and the other
via indentation. This redundancy aids in understanding that the code does
what you think it does.
 

In languages with explicit blocking, the delimiters determine what the code does.  The indents show the human reader what the code is supposed to do.  These are, hopefully, the same thing - but they might not be. In Python, as there is only one source of blocking, there is no possibility of such an error (once you have ensured you have no mix of tabs and spaces).
Redundancy is only a help if there is a way to automatically check and enforce consistency.  Without that, redundancy can be worse than useless - if the two methods get out of sync, the casual reader will misunderstand the code, and the careful reader will see there is a problem but not know what it is.
So for languages with explicit blocking, you need to be absolutely committed to keeping consistency, and use the tools you have - editors with automatic indents, gcc's "-Wmisleading-indentation" warning, and anything else to ease the cognitive burden and reduce the risk of inconsistencies.
With Python, that is simply not an issue.
(Another example of such redundancy is when people put comments saying what a piece of code does, rather than making the code itself clear. Changes to the code can easily lead to comments getting out of sync with the code, leading to confusion and misunderstanding.)

Python gets rid of this redundancy, by having the compiler take notice of
the whitespace and removing the statement bracketing symbols. So I put it
back, by adding statement bracketing symbols that the compiler ignores.

And that is worse than useless.
At least with languages that have explicit block delimiters, the compiler will always have some checks on consistency.  And tools (either compiler warnings, advanced editors, linters, etc.) can do more advanced checks.  With comments, you have nothing.