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

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?

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

 That's not the conventional way to format a docstring.  If you're using
backslashes to splice lines in Python, it's likely you're doing
something wrong.

Agreed 100%.

 

         for key in kwargs :
             if kwargs[key] :
                 if key == "managed_objects" :
                     if self._managed_objects != None :

 I think "is not None" is more idiomatic.

I don't know if that is true or not that it is more idiomatic - I would certainly be happy with either.
     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)
         """
         if managed_objects :
             if self._managed_objects != None :
                 raise asyncio.InvalidStateError("object manager interface already registered")
             self.register(
                 path = "/",
                 interface = ManagedObjectsHandler(),
                 fallback = True
             )
             self._managed_objects = {}
         return self
(Usenet formatting is limited to 72 characters standard - modern programming is not.  Overly long lines are not good, but a hard limit at, say, 80 characters is a bad idea.)

 

                         raise asyncio.InvalidStateError \
                           (
                             "object manager interface already registered"
                           )

 You don't need the \ if you put the ( on the same line.

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

 

                     #end if
                     self.register \
                       (
                         path = "/",
                         interface = ManagedObjectsHandler(),
                         fallback = True
                       )

 Again, you've decided how you want to place parentheses and you're
forcing the syntax to cater to that.  I might write that as:
                      self.register(
                         path = "/",
                         interface = ManagedObjectsHandler(),
                         fallback = True
                     )
 

                     self._managed_objects = {}
                 else :

 You leave a space between "else" and ":".  It's not wrong, but it's not
something I've ever seen.  It's likely to be just a little jarring to
readers.

I personally prefer a space before the colon in Python.  It is probably less common than no space, but it is certainly not a rare habit.

 

                     raise TypeError("unrecognized argument keyword “%s”" % key)

 Do you have a requirement to use older versions of Python that don't
support f-strings?
 

                 #end if
             #end if
         #end for
         return \
             self

 Why not just "return self"?

Indeed.

 

     #end register_additional_standard
>
versus
>
     def register_additional_standard(self, **kwargs) :
         "registers additional standard interfaces that are not automatically" \
         " installed at Connection creation time. Currently the only one is" \
         " the object-manager interface, registered with\n" \
         "\n" \
         "    «conn».register_additional_standard(managed_objects = True)\n"
         for key in kwargs :
             if kwargs[key] :
                 if key == "managed_objects" :
                     if self._managed_objects != None :
                         raise asyncio.InvalidStateError \
                           (
                             "object manager interface already registered"
                           )
                     self.register \
                       (
                         path = "/",
                         interface = ManagedObjectsHandler(),
                         fallback = True
                       )
                     self._managed_objects = {}
                 else :
                     raise TypeError("unrecognized argument keyword “%s”" % key)
         return self

 Again, the #end comments don't make it any more readable *for me*.
I suspect that would be even more true for more experienced Python
programmers.

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.

 

I was looking for quite a tricky example I remember seeing on the
ArjanCodes channel on YouTube, but I can’t find it.

 In any language, if a block of code is so deeply indented that it's
confusing, you should consider refactoring it.  (Though that's not
always the answer.)

Agreed.

 I once reviewed some C code with misleading indentation.  Depending on
the viewer's tab settings (4 vs 8 columns) it looked either like this:
      if (condition)
         this;
         that;
 or like this:
      if (condition)
         this;
     that;
 Of course it meant the same to the compiler.

As someone who works with C programming that is often high-reliability (not necessarily safety critical, but updates after production can be very expensive), both are unacceptable in the kind of coding standards we use.  I accept single-line "if" statements without braces if they are simple enough, otherwise braces are required.
if (condition) return;
if (condition) {
return;
} else {
break;
}
If the "true" statement is on a separate line, braces are /always/ required for my type of code.  Almost any indentation is done inside a pair of braces - it keeps everything simple and consistent, and it's easy to spot mistakes.

 In any language, I think it's important to use consistent indentation
that reflects the structure of the code, and to avoid mixing tabs and
spaces.  (My personal preference is to use spaces exclusively, but I'll
conform to what existing code does.)  As I've said elsethread, Python's
rules just force me to do what I would have done anyway.
 

I do the same.  (Well, I use tabs more than spaces, but otherwise I do the same.)