[Python-de] Re: Code Style Review

On Tue, Nov 29, 2022 at 06:18:38PM +0100, Stefan Schwarzer wrote:
> Erst mal zum Thema der Konfigurations-Speicherung, was in
> dem Diskussions-Thread auch aufgegriffen wurde. Da in Python
> Module und Klassen natürliche Singletons sind, wäre mein
> Vorschlag, die Konfigurations-Daten in einer Klasse zu
> speichern, also
> 
> ```
> class config:
> 
>     # Listener IP address and port of MQTT server.
>     ip_address = None
>     port = None
> 
>     # If `True`, print debugging output.
>     debug = False
> 
>     ...
> ```
> 
> Du kannst einfach von überall aus dem Modul auf das
> `config`-Objekt zugreifen und brauchst auch kein `global`.
> Die Klasse wird nie instanziiert, sondern nur als Namespace
> benutzt.

Habe ich ausprobiert, funktioniert. Nur pylint meckert:
too-few-public-methods: Too few public methods (0/2)

Ist das sowas ähnliches wie eine @dataclass?

Und eigentlich ist das doch auch nur ein Satz globaler Variablen auf
Steroiden.

> Der Ansatz hat gegenüber dem `config`-Dictionary auch den
> Vorteil, dass du dokumentieren kannst, wofür die einzelnen
> Werte gedacht sind. Ich halte es für gut, in `config` alle
> Werte auf Default-Werte zu setzen, selbst wenn diese mangels
> eines sinnvollen Defaults erst mal `None` sind. Das hat den
> Vorteil, dass man sehen kann, was jemals gesetzt wird und
> reduziert die Verwirrung, weil man nicht zwischen `None` und
> "gar nicht gesetzt" unterscheiden muss.

Andererseits muss ich halt jede auftretende Konfigurationsvariable an
mindestens zwei zusätzlichen Stellen explizit hinschreiben, während sich
das bei einem confighash direkt selbsttätig ergibt.

> Ich würde die Kommandozeilen-Optionen von den
> `config`-Attributen getrennt halten, um nicht die Konzepte
> Kommandozeilen-Parsen und Konfiguration zu vermischen. Das
> ist aber vielleicht ein Detail.

Ich finde es eigentlich ganz gut, wenn es für Konfigurationsvariablen
auch eine entsprechende Kommandozeilenoption gibt. Auf diese Weise kann
man die regelmäßig verwendeten Optionen in die Konfigurationsdatei
schreiben und wenn man es doch mal anders braucht auf der Kommandozeile
überschreiben.

> Zu den Debug-Ausgaben: Da kannst du den Code etwas
> vereinfachen, indem du die Abfrage des Debug-Flags in eine
> Funktion verschiebst, die du aufrufst.

Das habe ich jetzt mit dem Logging-Modul gemacht. Der Nachteil ist nur
dass ich jetzt meiner Tabellenklasse selbst beibringen muss, sich
auszudrucken, weil ich sonst durch die kompletten Bewegungen des
Ausdrucks gehe und im Zweifel nur die eigentliche Ausgabe unterdrücke.

> Für `element` würde ich statt Dictionarys `namedtuple`s oder
> Instanzen von `SimpleNamespace` verwenden. Allgemein sehen
> Zugriffe auf Dictionarys aus meiner Sicht immer recht
> "noisy" aus.

Das lasse ich erstmal, habe mir das notiert.

Grüße
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
_______________________________________________
python-de Mailingliste -- [email protected]
Zur Abmeldung von dieser Mailingliste senden Sie eine Nachricht an [email protected]
https://mail.python.org/mailman3/lists/python-de.python.org/
Mitgliedsadresse: [email protected]