Das deutsche Python-Forum

Nachdem ein vorheriges Forenthema 'explodiert' war https://www.python-forum.de/viewtopic.php?f=1&t=53489 habe ich mir überlegt: was war da los und was könnte man machen?

Gekommen bin ich auf den Titel "Python 'Benzingespräche'" - dieser könnte ganz gut passen, denke ich, um Python bezogene Dinge frei von Sachzwängen zu diskutieren, ob tiefer oder flacher, mit formal 'korrekter' Sprache oder eben 'slang' - alles wäre unter diesem Titel möglich, so lange es Python Bezug beinhaltet und kein eigenes Thema benötigt.

Hoffe, das Thema ist gut platziert und keine direkte Wiederholung von bereits Abgelegtem?

Möchte hier erst mal manches aufgreifen, was u. a. auch von Seiten @__blackjack__ eingeworfen wurde.

Obwohl scheinbar 'einfach' zeigte sich, dass ein Begriff wie 'Konstante' umfänglichen Klärungsbedarf hervorrufen kann - je nach Sachlage und Blickwinkel sicherlich 'zurecht'.

Eine Konstante wird ja gemäß PEP8 IN_GROßBUCHSTABEN geschrieben. Macht die Sache ja klarer, u. a. für den Programmierer, keine Frage.

Wenn ich nun im konkreten Fall einen Namen zur Verwendung für default-settings habe (ein dict mit wenigen key-value Paaren), haben wir hier eine Konstante, meine auch ich. Von irgendwo müssen Einstellungen (settings) ja kommen, so lange es keine individuellen user-Einstellungen gibt.

Bein allerersten Aufruf des Programms kommt allerdings der user interaktiv ins Spiel (so der Programmlauf), der innerhalb der ersten Minute die defaults auf seine Bedürfnisse anpasst. Die Datenstruktur einschl. der Namen der (keys der/des dict) bleibt dabei identisch. Werte können sich verändern.

Nun steht der Programmierer vor der Wahl und fragt sich:
Wie mach ich das jetzt?

Er hat die Wahl:
1) Zwei Namen
- einen für eine konstante Datenstruktur
und
- einen für eine angepasste Datenstruktur identischen strukturellen Inhalts

oder
2) Einen einzigen Namen
für "beide" Datensätze, den er deshalb von vorneherein als 'variabel' definiert

Nun kommt auch noch der 'hobgoblin' als der erste Spruch im PEP ins Spiel ( https://pep8.org/#a-foolish-consistency ... ttle-minds ). Der gefällt mir

Nach all diesen Erwägungen entscheidet sich der Programmierer in diesem Fall dafür, keine zwei, sondern nur eine einzige Datenstruktur zu verwenden. Wissend, dass die Style-Regeln nicht in allen Aspekten zu 100% befolgt wurden.

Seine wesentliche Begründung dabei ist:
Die Lebensdauer der Konstanten im Vergleich zur Variablen mit permanenter Bedeutung für den Programmablauf (ca. "eine Minute" zu Gesamtlebensdauer des Programms) ist verschwindend gering und rechtfertigt für diesen Fall nicht die Verwendung einer zweiten Struktur, der Konstanten.
Eine zweite Struktur würde den "Gesamtaufwand" in jeder Hinsicht (vergleichsweise) eher erhöhen als vermindern.

Dies mag Geschmacksache sein und ist diskutabel - bin gespannt, wie das am "Ende" aussieht.

Ich verstehe nicht, warum du das Thema separiert hast. Du diskutierst doch die gleichen Inhalte hier. Ich finde auch nicht, dass das Thema explodiert wäre. Die Diskussionen werden immer mal ein bisschen angespannter, aber das war noch lange nicht auf einem Niveau, dass ein Abkühlen der Gemüter verlangt.

Und inhaltlich ist die Sache in meinen Augen simpel: Code wird mehr gelesen, als geschrieben. Und genau dafür gibt’s die Konventionen. Sie sollen das lesen vereinfachen. Das deine Konstante keine solche ist, kann also für Verwirrung sorgen bei jemand anderem. Und jemand anderes, das kannst auch du in 3 Monaten sein. Darum ist das Votum da simpel und klar: sollte halt auch wirklich konstant sein.

Das du das anders handhabst, kann keiner verhindern. Will auch niemand. Du wirst aber auch keine Absegnung bekommen. Denn jeder der erfahreneren Diskutanten würde es eben anders lösen.

ulipy hat geschrieben: Mittwoch 1. Dezember 2021, 10:26 ... um Python bezogene Dinge frei von Sachzwängen zu diskutieren...

Achso, ich dachte das gesamte Forum würde zu diesem Zweck existieren

Es wäre vielleicht klarer gewesen, wenn du irgendwas mit "...Schreibweise von Konstanten..." in den Titel geschrieben hättest

Was der Programmierer macht ist seine Entscheidung. Er muss dafür die Verantwortung tragen.
Für Code den er im öffentlichen Raum freigibt kann er möglicherweise Kommentare bekommen, die er akzeptieren kann oder nicht. Auch das ist seine Entscheidung für die er die Verant... usw.

Ich fand die Erklärung von __blackjack__ im vorherigen Thread ziemlich treffend. Für mich habe ich die simple Definition daraus abgeleitet:
Eine Konstante ist ein Name, der auf Modulebene definiert ist und an den Daten gebunden sind, die sich zur Laufzeit nicht ändern sollen.
Namen von Konstanten enthalten nur Großbuchstaben und Unterstriche.

Edit:

Die Lebensdauer der Konstanten im Vergleich zur Variablen mit permanenter Bedeutung für den Programmablauf (ca. "eine Minute" zu Gesamtlebensdauer des Programms)

Was meinst du mit "Lebensdauer"? Woher kommt die eine Minute? Was passiert mit der Konstanten nach einer Minute? Müssen wir vom Schlimmsten ausgehen...?

@ulipy: Vielleicht hilft dir die Unterscheidung in Konstanten, Settings und Status. Konstanten ändern sich nie. Settings haben üblicherweise default-Werte, die durch Konstanten gesetzt werden. Status können während der Laufzeit anfallende Informationen sein, die persistent sind und den Neustart eines Programms überdauern (so wie Settings auch).

Konstanten werden in Python per Konvention in Uppercase gehalten, bei Settings lässt sich das auch machen: django geht so vor. Dort werden in einem separaten Modul die Settings definiert und überladen dabei die default-Werte, die in einem anderen Modul vorgegeben sind. Ob der Aufwand für jedes Programm sinnvoll ist sei dahingestellt.

Ansonsten gibt es die Möglichkeit, Settings nicht im Quelltext vorzuhalten, sondern diese aus z.B. einer ".ini" Datei zu lesen; dank dem "configparser" Modul aus der Standard Library ist das auch leicht umsetzbar. Zudem hat dies den Vorteil, dass der Nutzer nicht an den Quellcode muß (immer eine gute Idee, aber ich glaube, das hatte ich bereits in dem anderen Thread erwähnt).

Und bezüglich Status könnte sich für dich ein Blick auf das "shelve" Modul aus der Standard Library lohnen.

Das sind auch keine "Benzingespräche". Niemand zündelt hier. Lass dich einfach darauf ein, dass im Vergleich zu manchen anderen Sprachen Python etwas anders tickt.

Das sind auch keine "Benzingespräche". Niemand zündelt hier. Lass dich einfach darauf ein, dass im Vergleich zu manchen anderen Sprachen Python etwas anders tickt.

Python tickt so anders nicht und hat da auch noch vergleichsweise pragmatische Konventionen. Rust löst dass wesentlich weniger pragmatisch mit Compiler Warnungen z.B. bei globalen Variablen die nicht upper case sind.

Grundsätzlich hab ich den Eindruck dass sowohl mit Rust und Go was formatting angeht die Richtung in eine wesentlich weniger pragmatische geht, um Konsistenz zu erreichen und sich solche Diskussionen zu ersparen. Alles was der Compiler akzeptiert und rustfmt/gofmt ausgeben ist dann einfach richtig.

@ulipy: In dem ursprünglichen Thread hast du angedeutet, dass deine Settings irgenwie Konstanten sind, weil das ja ein dict ist, in dem die Schlüssel sich nicht ändern. Mit der Argumentation sind alle Variablen Konstanten - denn der Name der Variablen ändert sich ja nicht - nur der zugewiesene Wert.

Ansonsten wurde hier schon alles gesagt.

Das kann man sich ja mit black & co auch bei Python "ranzuechten". Benutzen wir natuerlich via git-hooks auch, so dass der Stil vorgeschrieben ist.

@__deets__
Es geht hauptsächlich um die für einen Neuling noch überschaubare Fokussierung auf begrenzte Themen.
Diese Fokussierung kann dagegen in einem thread 'Benzingespräche' auch komplett entfallen, wenn sich das so ergibt.

Im selben Zusammenhang fand ich die Möglichkeit zur Unterscheidung zwischen on- und offtopic "schwierig" - für mein Gefühl glitt vieles viel zu weit ab, natürlich auch durch meine Beiträge selbst verursacht..
Das ist halt ein Balanceakt in einem Forum und stark subjektiv. Die dabei entstehende "Hitze" war auch in meinen Augen unproblematisch.

Mit jeweils separat gestellten "Allgemeinen Fragen" kommt das dann deutlich besser hin - so der Gedanke.

Konstante:
Es ist nicht ausgeschlossen, dass ich diese in diesem Fall irgendwann verwende - das Bauchgefühl, "der große Integrator" - gibt immer noch kein klares "go"..

Entscheidend ist derzeit - und da beißt sich die Katze in den Schwanz - die begrenzte Lesbarkeit des codes durch mich selbst - ein Bootvorgang eben

rogerb hat geschrieben: Mittwoch 1. Dezember 2021, 12:30 ...
Eine Konstante ist ein Name, der auf Modulebene definiert ist und an den Daten gebunden sind, die sich zur Laufzeit nicht ändern sollen.
...

"DEFAULT_SETTINGS" würden halt noch innerhalb des ersten Programmaufrufs für die Ewigkeit obsolet - sie werden deshalb gleich "settings" genannt - so spare ich auch die "user_settings"

Komplexe settings anderer Programme könnten sogar den hier geplanten Gesamtumfang überschreiten. In diesem Fall wäre dies absolut nicht zu empfehlen...

kbr hat geschrieben: Mittwoch 1. Dezember 2021, 14:01 @ulipy: Vielleicht hilft dir die Unterscheidung in Konstanten, Settings und Status...
...

...
Das sind auch keine "Benzingespräche". Niemand zündelt hier. Lass dich einfach darauf ein, dass im Vergleich zu manchen anderen Sprachen Python etwas anders tickt.

Hallo @kbr,
können wir nochmals zurück zum code? So könnte deine Verwendung der o. a. Begriffe direkt auf das Beispiel bezogen werden.

Code: Alles auswählen

... ...
	# wir haben 5 key value Paare insgesamt als "settings"
	# gleich, genau "wann" und unter welchen Bedingungen
	
	# system defaults:
        'del_orphaned': False
        'demo_only': False
        'hide_versions': False
        'symlinks_dirs': False
        'symlinks_files': False
	...

Du gibst nun dem user beim initialen Start die Möglichkeit, keinen oder auch jeden dieser Werte an seine Bedürfnisse anzupassen (kein GUI, Kommandozeile).
Dann schreibst du das fest auf Platte.
Das, was danach von Platte gelesen wird, sind per Definition user settings.
Aus dem script wird das danach "nie mehr" benötigt oder gelesen.

In welche "Teile" würdest du den Sachverhalt trennen (Konstante, Settings und Status)?

Zum 'Benzingespräch': finde ich nicht daneben - sehe dies für diesen Zweck durchaus positiv

Du gibst nun dem user beim initialen Start die Möglichkeit, keinen oder auch jeden dieser Werte an seine Bedürfnisse anzupassen (kein GUI, Kommandozeile).
Dann schreibst du das fest auf Platte.

Warum stehen die Initialwerte nicht schon vorher in einer Konfigurationsdatei oder "auf Platte", was das auch immer bedeutet: Initialwerte lesen, vom Benutzer ändern lassen, neue Werte zurückschreiben.

DasIch hat geschrieben: Mittwoch 1. Dezember 2021, 15:33 Alles was der Compiler akzeptiert und rustfmt/gofmt ausgeben ist dann einfach richtig.

Wohl dem, der einen Compiler hat. Bei Python bedarf es zusätzlicher Tools.

kbr hat geschrieben: Mittwoch 1. Dezember 2021, 17:41 Wohl dem, der einen Compiler hat. Bei Python bedarf es zusätzlicher Tools.

Ändert der Compiler denn die die Formatierung des Quell-Codes? Python's Compiler versteht die schlechte Formatierung auch zu einem bestimmten Grad

@DasIch: In Python ist das aber auch üblich das IDEs solche Konventionsverstösse anmahnen, und die meisten Plugins/Pluginsammlungen, die Editoren mit Python-Unterstützung versorgen, haben das üblicherweise auch an Bord. Pylint, Flake8, oder etwas vergleichbares. Und Black wurde ja auch schon erwähnt.

@ulipy: Ich sehe nicht, dass `DEFAULT_SETTINGS` für alle Zeiten obsolet wird nach dem ersten Programmlauf. Das sind immer noch die Grundeinstellungen, die auch immer noch gebraucht werden, wenn die Einstellungsdatei mal nicht da ist, absichtlich oder wegen einem ”Unfall”. Manchmal möchte man als Benutzer, der ein Programm konfiguriert und da Probleme hat, oder aus anderen Gründen, wissen was die Grundeinstellung ist, an der man irgendwann mal etwas verändert hat.

Und es ist ja auch nicht so als wenn das irgendwie was frisst oder so. Man spart nichts wenn man eine Konstante im Programm hat, die hauptsächlich beim ersten Programmlauf benutzt wird. Wenn die paar Bytes tatsächlich wichtig sind, dann ist Python an sich die falsche Wahl. Wie wahrscheinlich die meisten modernen, dynamischen, Hochsprachen, und auch gleich einige der statisch typisierten mit.@DasIch: In Python ist das aber auch üblich das IDEs solche Konventionsverstösse anmahnen, und die meisten Plugins/Pluginsammlungen, die Editoren mit Python-Unterstützung versorgen, haben das üblicherweise auch an Bord. Pylint, Flake8, oder etwas vergleichbares. Und Black wurde ja auch schon erwähnt.

@ulipy: Ich sehe nicht, dass `DEFAULT_SETTINGS` für alle Zeiten obsolet wird nach dem ersten Programmlauf. Das sind immer noch die Grundeinstellungen, die auch immer noch gebraucht werden, wenn die Einstellungsdatei mal nicht da ist, absichtlich oder wegen einem ”Unfall”. Manchmal möchte man als Benutzer, der ein Programm konfiguriert und da Probleme hat, oder aus anderen Gründen, wissen was die Grundeinstellung ist, an der man irgendwann mal etwas verändert hat.

Und es ist ja auch nicht so als wenn das irgendwie was frisst oder so. Man spart nichts wenn man eine Konstante im Programm hat, die hauptsächlich beim ersten Programmlauf benutzt wird. Wenn die paar Bytes tatsächlich wichtig sind, dann ist Python an sich die falsche Wahl. Wie wahrscheinlich die meisten modernen, dynamischen, Hochsprachen, und auch gleich einige der statisch typisierten mit.

@rogerb: Nicht zwingend direkt der Compiler, aber es gibt Sprachen, da kommt ein Werkzeug zum automatisch formatieren von Quelltext schon in der Grundausstattung mit und kann über den ”Einstiegspunkt” aufgerufen werden, mit dem man auch kompilieren kann. Go wäre so eine Sprache.

Und wenn das so stark integriert ist, dann wird das in der Regel auch Teile vom Compiler mit benutzen, denn den Quelltext in Token zerlegen und einen Syntaxbaum aufbauen, müssen ja beide Werkzeuge. Wäre ja unsinnig den Teil dann zweimal zu implementieren.

rogerb hat geschrieben: Mittwoch 1. Dezember 2021, 17:24 ...
Warum stehen die Initialwerte nicht schon vorher in einer Konfigurationsdatei oder "auf Platte", was das auch immer bedeutet: Initialwerte lesen, vom Benutzer ändern lassen, neue Werte zurückschreiben.
...

Fest-"Platte" - es gibt ja heute kaum mehr welche... - die im M.2-Format sind ja fast "verboten" schnell...

Das Programm soll als Script ohne weitere Datei ausreichen, so der Plan.

__blackjack__ hat geschrieben: Mittwoch 1. Dezember 2021, 18:40 ...
@ulipy: Ich sehe nicht, dass `DEFAULT_SETTINGS` für alle Zeiten obsolet wird nach dem ersten Programmlauf. Das sind immer noch die Grundeinstellungen, die auch immer noch gebraucht werden, wenn die Einstellungsdatei mal nicht da ist, absichtlich oder wegen einem ”Unfall”. Manchmal möchte man als Benutzer, der ein Programm konfiguriert und da Probleme hat, oder aus anderen Gründen, wissen was die Grundeinstellung ist, an der man irgendwann mal etwas verändert hat.
...

Hallo @__blackjack__,
das trifft de facto schon zu, dass die defaults irgendwann doch wieder benötigt werden (eben z. B: nach einem "Unfall"), auch der Speicherbedarf ist kein Hindernis..

Derzeit steht das einfach nicht an - es ist von zu geringer Bedeutung und der "Schaden" ist ohne Mühe überschau- und handlebar.

Die Problemstellung ist eher akademischer Natur:
soll eine dermaßen winzige Aufgabe tatsächlich in u. U. sogar drei Teile zerrissen werden? ich bin immer noch der Überzeugung, dass dies dem Code nichts nützen würde in Sachen Konformität.

Da wären wir wieder an dem Punkt wo Du Sachen offenbar anders bewertest als alle anderen. Das Problem ist IMHO auch nicht akademischer Natur. Das ist sehr praxisrelevant ob sich Programmierer an allgemeine Konventionen halten und verständlichen und wartbaren Code schreiben oder eben nicht. Auch bei vermeintlich kleinen Programmen. Die bleiben nicht immer klein, und in x Jahren hat man dann selber Probleme mit angehäuftem „technical debt“ oder jemand anderes darf sich damit herum ärgern.

Ich sehe auch nicht so wirklich was das Problem ist. Was für riesengrosse Arbeit musst Du denn da investieren und wie viele KLOC Code sind das denn, die die Länge und Ausdauer und Zeit aufwiegen würden, die Du hier in diese fruchtlose, auf zwei Themen verteilte Diskussion steckst? Wir reden doch hier von Code der Art: Schaue ob Datei vorhanden, wenn nein lege Datei aus Defaultwerten an. Dann lade die nun auf jeden Fall bestehende Datei. Und das ist der Ablauf der in jedem Fall passieren muss. Wir reden also eigentlich nur davon ob die KEY_SETTINGS als Konstante oben im Modul sind, oder irgendwo mitten im Code stehen — Anzahl der Zeilen von dem ganzen Sums ist letztlich *gleich*!

@all
Diese "Sache" ist dank eurer Geduld und Hilfe endgültig durch!

Als Freund von Minimalismus und Neuling zu Python konnte ich es nicht umgehen, beharrlich nach einer sinnvollen, minimalistischen Lösung für ein scheinbar "kleines" Problem zu suchen.

Eine Abweichung von "in der Regel" befolgten Konventionen wäre dann vorgezogen worden, wenn dieses Herangehen auch nur ein winziges Fleckchen "pythonischen Boden" gefunden hätte, auf dem es hätte aufgebaut werden können - hat es aber nicht..

Im Sinne der Hilfestellung war dies dadurch in keiner Weise sinnlos - dem Neuling wurde aufgezeigt, was in diesem Sinne "nicht geht"..

Um gedanklich zunächst eine (neue) Pseudo-Skizzierung zu machen war die letzte Nacht ja lange genug

Ich stelle sie dann hier rein um zu sehen, ob der Ansatz 'pythonisch' in Ordnung wäre..

Bin nun auf der Suche nach alternativen Möglichkeiten der Umsetzung dieses Themas "settings".

Wäre denn eine Funktion oder eine Klasse zur besseren Kapselung das "Richtige"?

Eine Klasse würde im Umkehrschluss eine 180° - Wende zum bisherigen bedeuten: vom dict [ auf Ebene main() ] --> Klasse.

Vor einer konkreten Umsetzung wäre Feedback zu den damit verbundenen Fragen toll!

Zwei Randbemerkungen dazu:

die "Distribution" verwendet außer dem script selbst keine weitere Datei

default-settings könnten dann - so die aktuelle Denke - direkt in der Klasse selbst niedergelegt werden

Der code hier ist zwar funktional, jedoch sehr umständlich geschrieben und mit diversen Wiederholungen gespickt - "von Hand" halt, nicht mal "zu Fuß"...

Er kann sicherlich - auch lesbar für mich als Anfänger - um ca. 50% reduziert werden.

Code: Alles auswählen

import json

class MyClass:
    def __init__(self, name):
        # use function objects to set
        # defaults of key - value pairs?
        self.tmp = {} # key-val container

        self.demo_flag = True
        self.tmp['demo_flag'] = self.demo_flag

        self.any_item = 'some text'
        self.tmp['any_item'] = self.any_item

        with open('.\\df dfg ff _Y_TmP_mydata.json', 'w') as f:
            json.dump(self.tmp, f)

    def update(self, key, val):
        f = open('.\\df dfg ff _Y_TmP_mydata.json', 'r')
        self.tmp = json.load(f)

        if key == 'demo_flag':
            self.demo_flag = val
        elif key == 'any_item':
            self.any_item = val
        else:
            print('ERROR')
            quit()

        f.close()

        f = open('.\\df dfg ff _Y_TmP_mydata.json', 'w')
        json.dump(self.tmp, f)
        f.close()

# create instance x of MyClass,
# named "settings"
x = MyClass('settings')

print(f'instance: {x}')

print(f'x.demo_flag: {x.demo_flag}')

key = 'demo_flag'; val = False
x.update(key, val)

print(f'x.demo_flag: {x.demo_flag}')

quit()

Was meint ihr?

Viele Grüße
Uli

Das deutsche Python-Forum

Python 'Benzingespräche'

Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Re: Python 'Benzingespräche'

Eine Klasse für settings nehmen?