Python 'Benzingespräche'

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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?
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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 :D

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.
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

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.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

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...?
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

@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.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

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.
Benutzeravatar
sparrow
User
Beiträge: 4164
Registriert: Freitag 17. April 2009, 10:28

@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.
Zuletzt geändert von sparrow am Mittwoch 1. Dezember 2021, 16:02, insgesamt 1-mal geändert.
__deets__
User
Beiträge: 14493
Registriert: Mittwoch 14. Oktober 2015, 14:29

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.
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

@__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
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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...
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

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.
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

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.
rogerb
User
Beiträge: 878
Registriert: Dienstag 26. November 2019, 23:24

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
Benutzeravatar
__blackjack__
User
Beiträge: 13003
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@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.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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.
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

__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.
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
Benutzeravatar
__blackjack__
User
Beiträge: 13003
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

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*!
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

@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..
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
ulipy
User
Beiträge: 83
Registriert: Mittwoch 17. November 2021, 21:42
Wohnort: Ba-Wü

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
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
Antworten