Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #5884
| Path | csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail |
|---|---|
| From | Stefan Schwarzer <sschwarzer@sschwarzer.net> |
| Newsgroups | de.comp.lang.python |
| Subject | [Python-de] Re: Code Style Review |
| Date | Thu, 1 Dec 2022 23:58:31 +0100 |
| Lines | 84 |
| 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> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=UTF-8; format=flowed |
| Content-Transfer-Encoding | 8bit |
| X-Trace | news.uni-berlin.de BjK1HM4QKZqH4Wu4BwkJ+wHOphva46hVJv+8qVdUL07A== |
| Authentication-Results | mail.python.org; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral |
| User-Agent | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 |
| Content-Language | en-US, de-DE |
| In-Reply-To | <Y4kLkGxr+4DhQto0@torres.zugschlus.de> |
| X-Provags-ID | V03:K1:4yq7Wo74AvW6Ej9Vy6BNx6U4geEi4suyeN2cyFR6QW4J9Q9P6I8 tHPAV/YKRSgrcQn8omBLQG5D2mp9ShszbBw/oAsCHTTmQPzpSiPHdsujR/HYTzb5tGDHpPO BiMDZ0I6OTWoPzP6/tvt4ox+nNAaT9R8Zi+gS5DwfC7SaxHFJC2vWTtvU/oiEX10xE21arK GOrOXMODtHCJiSBcfoT3w== |
| X-Spam-Flag | NO |
| X-UI-Out-Filterresults | notjunk:1;V03:K0:Rt9kcT/HdZY=:H09mDRMXh2HII43s76xK0a PCUFi+YLZBQ1NdSiQZ0f0h4IojvfYqLvh7HeffDv4skK47OY7p000bsYRXJYIK18T4YQnBwKJ y10WejMh1yQRMpKFuFsRbrTpm8kT4IsF/Ak5Ki7rAKdz56xKQratC43S1rs/caAaW6zo+qcTE YZKSeFDBZyYyAdKO3oiH/OsOTjYDykGAImZFFsxgyaxsIorvTvfLOVjf3rcVDRokIq6qO/1J7 mwjyU2bzETlUtGn/+CRTIf628slTmtcoLbnEVJ32Rhlb2BX78ArtZ+jp4+h0Wsofp2o+XSWKB ObsonUKE4zkW4Yxs1IM7ij9yrqMz5rjO9Ugo6Y6w6oQheOHeAldd4xhHGbSwwmwI57OYh5kHb pw9vJdA3GwmOfySV7rWlTnTn/NhTZQGaQTGPKJcig3Jtk71GAJOiWhN8oueme+THE/maflcD7 Azg9MFcWpC7lWhV0uS9GUPYP4VrSp4xlHnKCcF26uNMXuO1crQ81UuXB80kqMkla+vk08cd4B QXboN0+InQloduOLd/+vHgf5aD2DoRFtbGo39xd3ttuvkf+EcvqkYpOtYXSRVAGaMLtye2/UM gNjXR8DvrE4M7HlQ/ETd1BoPkcggtlLX2b7UGzwvrkDudUUEMelLwT/H9M0MsssRtxfD5lo3K yUb5eBLL/4pdj+VdKO/Ih1m4szO1eimKVH25eYK/hK9X1Dne7p0jJQqNfYZ1OO7EHo6mTTfEz tjedlD6xcXrsPzcHhi3HLJknLHvSCcovpCF281buj7MTw6NxjZHiFmloolpL6p0XmunuJFwAN x4a2pBCd4VEDnw7HvmZd72cVKZp2w== |
| Message-ID-Hash | XU7Z3WOCRAY4ULIJLWXZKNTMUUGS4452 |
| X-Message-ID-Hash | XU7Z3WOCRAY4ULIJLWXZKNTMUUGS4452 |
| X-MailFrom | sschwarzer@sschwarzer.net |
| X-Mailman-Rule-Misses | dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-python-de.python.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header |
| X-Mailman-Version | 3.3.7 |
| Precedence | list |
| List-Id | Die Deutsche Python Mailingliste <python-de.python.org> |
| Archived-At | <https://mail.python.org/archives/list/python-de@python.org/message/XU7Z3WOCRAY4ULIJLWXZKNTMUUGS4452/> |
| List-Archive | <https://mail.python.org/archives/list/python-de@python.org/> |
| List-Help | <mailto:python-de-request@python.org?subject=help> |
| List-Owner | <mailto:python-de-owner@python.org> |
| List-Post | <mailto:python-de@python.org> |
| List-Subscribe | <mailto:python-de-join@python.org> |
| List-Unsubscribe | <mailto:python-de-leave@python.org> |
| Xref | csiph.com de.comp.lang.python:5884 |
Show key headers only | 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 | 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