Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.python > #5884

[Python-de] Re: Code Style Review

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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