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?
Python 'Benzingespräche'
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.
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.
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität
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.
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.
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:
Was meinst du mit "Lebensdauer"? Woher kommt die eine Minute? Was passiert mit der Konstanten nach einer Minute? Müssen wir vom Schlimmsten ausgehen...?Die Lebensdauer der Konstanten im Vergleich zur Variablen mit permanenter Bedeutung für den Programmablauf (ca. "eine Minute" zu Gesamtlebensdauer des Programms)
@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.
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.
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.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.
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.
Ansonsten wurde hier schon alles gesagt.
Zuletzt geändert von sparrow am Mittwoch 1. Dezember 2021, 16:02, insgesamt 1-mal geändert.
@__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
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
"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
Hallo @kbr,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.
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
...
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
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.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.
- __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.
@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
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
Hallo @__blackjack__,__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.
...
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
- __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*!
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
@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..
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
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:
Er kann sicherlich - auch lesbar für mich als Anfänger - um ca. 50% reduziert werden.
Was meint ihr?
Viele Grüße
Uli
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
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()
Viele Grüße
Uli
Py::: 1. funktional zuverlässig, 2. Anfänger-lesbar, 3. Py-Konformität