Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #5884
| From | Stefan Schwarzer <sschwarzer@sschwarzer.net> |
|---|---|
| Newsgroups | de.comp.lang.python |
| Subject | [Python-de] Re: Code Style Review |
| Date | 2022-12-01 23:58 +0100 |
| Message-ID | <62b38fd1-39a1-9867-9ac4-b50bda4a4ddd@sschwarzer.net> (permalink) |
| References | <tm2jhn$1k5h8$1@news1.tnib.de> <25b8d1d4-d6e2-22ee-4bed-ec76227fa65d@sschwarzer.net> <Y4kLkGxr+4DhQto0@torres.zugschlus.de> |
On 2022-12-01 21:16, Marc Haber wrote: > On Tue, Nov 29, 2022 at 06:18:38PM +0100, Stefan Schwarzer wrote: >> 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) Hihi, ja, das ist wieder das "Problem" mit Pylint. ;-) > Ist das sowas ähnliches wie eine @dataclass? `dataclass` ist ähnlich. Ich hatte auch daran gedacht, aber wollte es vermeiden, in die Diskussion abdriften, ob/wo man in Python explizite Typ-Angaben verwenden sollte. Daher habe ich den "normaleren" Ansatz vorgeschlagen. > Und eigentlich ist das doch auch nur ein Satz globaler Variablen auf > Steroiden. Ja, das kann man so sehen. Ich finde die Extra-Klasse ganz schön, um zusammengehörige Objekte zu gruppieren. Ich würde das hier wahrscheinlich machen, aber man kann auch argumentieren, dass es bei drei(?) Objekten in der Klasse auch ok ist, Variablen auf der Modul-Ebene zu verwenden. Letztlich ist das Geschmackssache, denke ich. >> 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. Yep, ist wieder eine Abwägung, also die Frage, welche Kombination von Vor- und Nachteilen man bevorzugt. >> 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. Wenn du eine starke Überschneidung zwischen der Konfiguration im allgemeinen und der Konfiguration von der Kommandozeile hast, ist das plausibel, nur eine Klasse/Namespace zu verwenden. Es gibt aber auch Fälle, wo es keine so starke Überschneidung gibt, zum Beispiel, weil Konfigurations-Einstellungen aus verschiedenen Quellen kommen (im Code hartverdrahtet, von der Kommandozeile, aus Konfigurationsdateien, etc.). Wenn das viel Konfiguration ist, muss/sollte man das aber wiederum gegebenenfalls anders angehen. Du entscheidest. :-) >> 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. Ich finde das gut, dass du mit verschiedenen Ansätzen experimentierst. Dann bekommst du ein noch besseres Gefühl dafür, welche Vor- und Nachteile verschiedene Ansätze haben. :-) Viele Grüße Stefan
Back to de.comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar
Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 16:19 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 15:37 +0000
[Python-de] Re: Code Style Review Christopher Arndt <chris@chrisarndt.de> - 2022-11-28 16:48 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 19:53 +0000
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 22:07 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:51 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-11-29 21:44 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 23:16 +0100
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-28 21:52 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-28 22:38 +0000
Re: [Python-de] Re: Code Style Review Enrik Berkhan <Enrik.Berkhan@inka.de> - 2022-11-29 06:03 +0000
Re: [Python-de] Re: Code Style Review Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-11-29 15:22 +0100
[Python-de] Re: Code Style Review c.buhtz@posteo.jp - 2022-11-29 14:39 +0000
[Python-de] Re: Code Style Review Matthias Urlichs <matthias.urlichs@noris.de> - 2022-11-30 10:47 +0000
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-01 21:30 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-12-02 00:07 +0100
Re: [Python-de] Re: Code Style Review "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-12-03 14:32 +0100
[Python-de] Re: Code Style Review Matthias Urlichs <matthias.urlichs@noris.de> - 2022-12-02 09:29 +0000
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-02 18:02 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:33 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-11-29 18:18 +0100
[Python-de] Re: Code Style Review Hans-Peter Jansen <hpj@urpla.net> - 2022-11-30 15:52 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-01 21:16 +0100
[Python-de] Re: Code Style Review Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2022-12-01 23:58 +0100
[Python-de] Re: Code Style Review Marc Haber <mh+python-de@zugschlus.de> - 2022-12-02 18:10 +0100
Re: [Python-de] Re: Code Style Review "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-12-03 14:36 +0100
csiph-web