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

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

[Python-de] Re: Code Style Review

Show key headers only | View raw

Am Dienstag, 29. November 2022, 18:18:38 CET schrieb Stefan Schwarzer:
> Hallo Marc,
> 
> On 2022-11-28 16:19, Marc Haber wrote:
> 
> > ich wollte mich schon seit Jahren mal etwas ernsthafter mit python
> > beschäftigen und hier ist mein Erstlingswerk signifikanter Länge.
> > pylint hat nichts auszusetzen, an manchen Stellen habe ich pylint aber
> > überstimmt.
> > 
> > Ist da irgendetwas drin, was nicht pythonesk genug formuliert ist?
> > 
> > Laufen tut das Programm jedenfalls.
> > 
> > Ich würde mich über Eure Kommentare freuen.
> 
> 
> ich habe hier und da ein paar Anregungen. Wie immer gilt,
> dass letztlich der Autor entscheidet, wie er/sie diese
> Anregungen umsetzt. :-)

+1

> 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.

Yep, dem kann ich mich nur anschließen, und ich praktiziere diese Methode seit 
Jahrzehnten. Bei mir heißt diese Klasse <gpar>, da es mit <config> häufig zu 
Überschneidungen von anderen Funktionalitäten kommt (z.B. config files).

Grundsätzlich gilt es dabei abzuwägen, ob Du diese Werte
 * direkt wie globals verwendest <gpar.value>
   -> für skriptnahe Routinen
 * deinen Funktionen/Methoden gpar als Parameter <func(gpar)> übergibst
   -> skriptnahe Funktionen/Instanzen, die viele der Werte brauchen
 * die Konfigurationswerte einzeln übergibst <func(gpar.v1, gpar.v2)>
   -> für universell wiederverwendbare Funktionen/Klassen/Methoden

Vorab, ich erhebe nicht den Anspruch, irgendwie ausgesprochen pythonistisch zu 
sein, und setze in manchen Bereichen ganz bewusst oldschool-Ansätze ein (z.B. 
getopt). Komme von einem systemnahen Assembler und C-Umfeld, und habe mit 
Python im letzten Jahrtausend angefangen. Seitdem nutze ich es überall, wo es 
die Wahl gibt, als überaus nützliches, universelles Werkzeug, dass immer noch 
Spaß macht! Letzteres ist eines der wichtigsten Aspekte für die Beliebtheit 
der Sprache, die nicht in irgendwelchen strategischen Charts ihren Einstieg in 
Industrie-Projekte gefunden hat (wie beispielsweise Java).

Zu dem schon Gesagten möchte ich noch ergänzen:

Aus Gründen der Flexibilität verwende ich für einfache Skripte folgendes 
Muster:

def main(argv = None):
    """Command line interface and console script entry point."""
    if argv is None:
        argv = sys.argv[1:]
    [...]
    return 0

if __name__ == '__main__':
    sys.exit(main())

So kannst Du den Funktionsumfang des Skripts direkt, von anderen Modulen und 
auch mit setuptools benutzen.

Die --help Ausgabe findet sich in meinen Skripten meistens im __doc__ Bereich 
des Hauptmoduls, wie Du auch schon damit angefangen hast. So habe ich auch die 
Dokumentation da, wo ich sie *will*. Neben vielen Vorteilen hat das aber auch 
den Nachteil, Kommandozeilen Optionen nicht an einer Stelle fokussiert 
abzufrühstücken. Das funktioniert gut bis zu einer gewissen Größe des 
Projekts. 

Wie das in echt aussieht, kannst Du Dir ja mal hier anschauen:

https://github.com/frispete/vpndnshelper/blob/main/vpndnshelper.py

Vielleicht findest Du da auch noch die eine oder andere Anregung. Da Du dich 
scheinbar auch in einem unixoiden Umfeld bewegst, könnten dich die signal und 
exception Behandlungen der main Funktion interessieren. Dieses Skript läuft 
übrigens üblicherweise als systemd Dienst, hat aber noch nie einen Linter 
gesehen (und ja, das sollte ich auch mal tun..).

Cheers,
Pete
--
Life without chameleons is possible, but pointless.

Back to de.comp.lang.python | Previous | Next — Previous 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