Recommended coding style

Development
1

I have started a critical review of the code. Here are preliminary remarks. I focused on the __init__ methods but it is likely that the same remarks may apply to others.

  • There remains many Python 2 class definitions (where they inherit from object)
    This is quite easy to fix, but it is spread out all over the source tree

  • Instance variables
    Since there is no variable declaration per se in Python, many classes do “neutral” initialisation (i.e. to 0, empty or None) in their __init__ method as a way to advertise variables created in this class. Approximately as many classes don’t follow this rule and simply set their local variables when needed, which is enough to create a variable in the local scope.
    What is the Gramps recommended style? Using the __init__ as a declaration reminder or making profit of Python relaxed rules?

  • Derived classes
    Many derived classes are only “specialisation” of a base class, differing only on some methods (frequently to apply default or ad hoc value to some arguments of the base class). I noticed that even if their __init__ method is strictly identical to the base class, the __init__ method is written again (duplicating the original).
    Is thera a documentary interest in duplicating the method vs. inheriting it from the base class?

  • Instance initialisation adding to base class
    Frequently subclasses add to base class definition (extra variables and methods). To guarantee error-free consistency, base class __init__ is requested before adding specific variables. Present coding is principally written as baseclass.__init__(self, …), much less frequently super().__init__(…). This is not consistent. super() has the advantage of being immune to inheritance changes but doesn’t hint to the actual inheritance (forcing to scroll back to read it).
    What is the Gramps recommended style?
    There are occurrences where variables are initialised before the __init__ call(s), resulting in the potential risk that variable initialisation is replaced by some initialisation in the parent class.
    Shouldn’t __init__ calls be grouped first before any subclass initialisation is done?

  • Multiple inheritance classes
    __init__ methods to base classes are explicitly called one after another as baseclass_i.__init__(self,…). Would it be worth to transform the base classes into “super()-cooperative” classes so that all this initialisation reduces to super().__init(…) in a more concise coding, although less “documenting” but immune to class modification?
    What is the Gramps policy regarding code concision vs. intuitively understood coding?

2

EDIT 2022-02-18:
super().__init__(…) doesn’t work because

  • classes are not Python-cooperative
  • GTK+ classes come in the way and neither cooperative
  • arguments passed to initialise multiple-inheritance classes are not “orthognonal”: some are shared by several superclasses (and can’t be eliminated after use) and it is difficult to predict which ones are really necessary at each step in the MRO
  • many classes seem to me badly structured (in a logical sense), mixing a functional role such as DB functions and a display role with GTK widgets without roles being clearly distinct

    Reverting to statu quo ante

    I’d be glad to receive comments about better code structuring.