Eine Konstante ist das falls der Benutzer das im Quelltext ändert bevor er das Programm laufen lässt. Oder umgekehrt, wenn das während des Programmlaufs nicht geändert wird. Also wenn das Programm nicht mehr funktioniert wenn man das Wörterbuch in ein `types.MappingProxy` verpackt, dann ist es keine Konstante und gehört dementsprechend auch nicht auf Modulebene, unabhängig von der Schreibweise des Namens. Ich habe das ja auch nicht `SETTINGS` genannt, weil ich davon ausging, dass Du da noch Einstellungen aus JSON lädst und in `DEFAULT_SETTINGS` nur die *Voreinstellungen* drin sind, die gegebenenfalls durch Werte aus der JSON-Datei ”überstimmt” werden. Zum Beispiel in dem man beide Wörterbücher in einer `collections.ChainMap` verbindet.
Und wenn ich Vermutungen über die Bedeutung von den Schlüsseln anstelle, sieht einiges davon auch so aus, als wenn es dafür ganz gut Kommandozeilenargumente geben könnte.
Diverse Syntax Problemchen..
-
__blackjack__
- User
- Beiträge: 13121
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
So schaffen wir das niemals, auch nicht mit Hilfe eines redlich bemühten Murphy...
Eine Handvoll Wörter würden genügen - wie kommen wir da wieder raus???
* ein "user" ist derjenige, der das Programm nutzt, nicht derjenige, der das Python script schreibt
* die geplanten settings (alles key-value) enthalten zwei Arten von settings:
- a) einen Zähler
dieser wird verwendet ausschließlich intern, vom Programm selbst. er zählt die Anzahl der durch den user ausgelösten Programmaufrufe hoch (war leider als Konstante = 0 im code kommentiert..)
Den kann man sicher woanders auch unterbringen - dafür gibts aber momentan keine Not.
- b) weitere key-val-Paare, welche den Programmablauf beeinflussen
diese werden beim ALLERERSTEN durch den user ausgelösten Programmaufruf vom Programm selbst in die json geschrieben.
(davor gibt es außer dem script (und einem funktionalen Python3 -
) noch nix Weiteres auf der Festplatte des users)
Nach diesem Punkt im ersten Aufruf (ob nun im selben oder in einem der folgenden Aufrufe), kann der user davon abweichende Einstellungen (settings) tätigen. Die genaue Abfolge solcher Möglichkeiten gehört nicht hierher.
Und diese settings werden - um sie dauerhaft festhalten zu können - nach jeder Änderung in der json abgespeichert.
Und ja, es wird auch Kommandozeilen-Parameter geben, die settings betreffend - aber das interessiert hier ja nicht.
Selbstverständlich wollen diverse Programmteile / Funktionen dann und wann auf einen oder auf mehrere werte in den settings zugreifen, abhängig vom script halt. Das ist dann eine globale Verwendung, keine Frage.
Und das ist dann nicht die "böse" Art der Verwendung - denke ich.
Also ist meine Frage bleibt nach diesem Exkurs erhalten:
Ist "dieses" settings nun eine Konstante im Sinne von PEP 8 oder ist es dies nicht?
Falls die Antwort "42" ist, braucht sie natürlich nicht extra erwähnt zu werden - lediglich wenn das eine KONSTANTE wäre, hätte ich überraschendes aus Python dazugelernt
Eine Handvoll Wörter würden genügen - wie kommen wir da wieder raus???
* ein "user" ist derjenige, der das Programm nutzt, nicht derjenige, der das Python script schreibt
* die geplanten settings (alles key-value) enthalten zwei Arten von settings:
- a) einen Zähler
dieser wird verwendet ausschließlich intern, vom Programm selbst. er zählt die Anzahl der durch den user ausgelösten Programmaufrufe hoch (war leider als Konstante = 0 im code kommentiert..)
Den kann man sicher woanders auch unterbringen - dafür gibts aber momentan keine Not.
- b) weitere key-val-Paare, welche den Programmablauf beeinflussen
diese werden beim ALLERERSTEN durch den user ausgelösten Programmaufruf vom Programm selbst in die json geschrieben.
(davor gibt es außer dem script (und einem funktionalen Python3 -
) noch nix Weiteres auf der Festplatte des users)Nach diesem Punkt im ersten Aufruf (ob nun im selben oder in einem der folgenden Aufrufe), kann der user davon abweichende Einstellungen (settings) tätigen. Die genaue Abfolge solcher Möglichkeiten gehört nicht hierher.
Und diese settings werden - um sie dauerhaft festhalten zu können - nach jeder Änderung in der json abgespeichert.
Und ja, es wird auch Kommandozeilen-Parameter geben, die settings betreffend - aber das interessiert hier ja nicht.
Selbstverständlich wollen diverse Programmteile / Funktionen dann und wann auf einen oder auf mehrere werte in den settings zugreifen, abhängig vom script halt. Das ist dann eine globale Verwendung, keine Frage.
Und das ist dann nicht die "böse" Art der Verwendung - denke ich.
Also ist meine Frage bleibt nach diesem Exkurs erhalten:
Ist "dieses" settings nun eine Konstante im Sinne von PEP 8 oder ist es dies nicht?
Falls die Antwort "42" ist, braucht sie natürlich nicht extra erwähnt zu werden - lediglich wenn das eine KONSTANTE wäre, hätte ich überraschendes aus Python dazugelernt
-
__blackjack__
- User
- Beiträge: 13121
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@ulipy: User ist halt nicht immer so klar getrennt von Programmierer wenn es um Programme geht die irgendwelche Systemautomatisierung oder so machen. Da hat man oft Konstanten im Programm die der Benutzer an *sein* System anpassen kann, manchmal sogar muss, bevor das Programm sinnvoll laufen kann.
Welches Settings meinst Du denn jetzt mit ”dieses”? Wenn das Programm alle Einstellungen erstmalig auf Platte schreiben soll, dann müssen die ja im Programm hinterlegt sein. Zum Beispiel als Konstante `DEFAULT_SETTINGS` die nie verändert wird. Das sind dann ja aber andere Einstellungen als die, die man einliest und dann im Programm verwendet.
Und was das zugreifen auf globale Strukturen angeht, einfach so magisch, ohne das da Argumente an Funktionen übergeben werden, ist das vielleicht nicht zwingend absolut abgrundtief Böse™, IMHO aber unschön bis komisch riechend. Ich würde das vielleicht so versuchen festzunageln: Wenn man keine Unittests schreiben kann die gute Abdeckung über alle Zweige in den Funktionen haben *und* paralellel ausgeführt werden können, dann hat man spätestens dann ein Problem, wenn man in solchem Code Fehler suchen muss, weil der ungünstig über nicht leicht durchschaubaren globalen Zustand zusammenhängt.
Welches Settings meinst Du denn jetzt mit ”dieses”? Wenn das Programm alle Einstellungen erstmalig auf Platte schreiben soll, dann müssen die ja im Programm hinterlegt sein. Zum Beispiel als Konstante `DEFAULT_SETTINGS` die nie verändert wird. Das sind dann ja aber andere Einstellungen als die, die man einliest und dann im Programm verwendet.
Und was das zugreifen auf globale Strukturen angeht, einfach so magisch, ohne das da Argumente an Funktionen übergeben werden, ist das vielleicht nicht zwingend absolut abgrundtief Böse™, IMHO aber unschön bis komisch riechend. Ich würde das vielleicht so versuchen festzunageln: Wenn man keine Unittests schreiben kann die gute Abdeckung über alle Zweige in den Funktionen haben *und* paralellel ausgeführt werden können, dann hat man spätestens dann ein Problem, wenn man in solchem Code Fehler suchen muss, weil der ungünstig über nicht leicht durchschaubaren globalen Zustand zusammenhängt.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman
@__blackjack__
ich versuchs nochmal, obwohl dies eigentlich der Tod dieses Threads war, da die kommunikation nicht mehr möglich war.
* ok, user ist nun für diesen Fall geklärt
* ja klar, die defaults sind im Programm hinterlegt - woraus entnimmst du, dass dies nicht der Fall wäre? Das war ja nicht das Thema
* die dynamischen Änderungen an den settings wurden auf vielfache Weise geklärt
* auf unittestts wird bis auf Weiteres bei einem geplanten Umfang von lediglich viel. 2000 zeilen code innerhalb einer einzigen skript-Datei verzichtet
* sicherer als das Lesen und Schreiben dieses settings-dictionaries von beliebiger Stelle im Programm über eine Python-Funktion braucht das nicht gemacht sein. jeder halbwegs "mündige" Programmierer findet diese Funktion bei Bedarf [ctrl] + [f] "Begriff" oder so ähnlich
Nirgends wurde behauptet, dass ein Schreibzugriff direkt im dict erfolgen soll, an beliebiger Stelle - eine solche Idee wäre tatsächlich nicht so doll
* das mit der Magie ist ja nun auch geklärt, meine ich
* das mit der Sucherei auch
ich versuchs nochmal, obwohl dies eigentlich der Tod dieses Threads war, da die kommunikation nicht mehr möglich war.
* ok, user ist nun für diesen Fall geklärt
* ja klar, die defaults sind im Programm hinterlegt - woraus entnimmst du, dass dies nicht der Fall wäre? Das war ja nicht das Thema
* die dynamischen Änderungen an den settings wurden auf vielfache Weise geklärt
* auf unittestts wird bis auf Weiteres bei einem geplanten Umfang von lediglich viel. 2000 zeilen code innerhalb einer einzigen skript-Datei verzichtet
* sicherer als das Lesen und Schreiben dieses settings-dictionaries von beliebiger Stelle im Programm über eine Python-Funktion braucht das nicht gemacht sein. jeder halbwegs "mündige" Programmierer findet diese Funktion bei Bedarf [ctrl] + [f] "Begriff" oder so ähnlich
Nirgends wurde behauptet, dass ein Schreibzugriff direkt im dict erfolgen soll, an beliebiger Stelle - eine solche Idee wäre tatsächlich nicht so doll
* das mit der Magie ist ja nun auch geklärt, meine ich
* das mit der Sucherei auch
-
__blackjack__
- User
- Beiträge: 13121
- Registriert: Samstag 2. Juni 2018, 10:21
- Wohnort: 127.0.0.1
- Kontaktdaten:
@ulipy: Es ging doch um die Frage ob/was eine Konstante ist, und die Default-Settings sind eine. Und mir war jetzt nicht klar ob Du da eine Trennung zwischen dieser Datenstruktur machst und der wo die Settings aus der externen Datei eingelesen werden.
Die dynamische Änderung an den Settings ist mir auch nicht klar. Also eigentlich sollten die ja gar nicht geändert werden IMHO, also nicht im Programm. Deine Texte klingen aber teilweise so als wenn die JSON über das Programm verändert werden soll und nicht extern in einem Texteditor wie das IMHO normal wäre. Aber ein Programmstartzähler hat da ja zum Beispiel auch nichts zu suchen. Hatte ich nur nichts zu gesagt weil Du das ja wohl selbst weisst.
Ob Du Unittests machst oder nicht war nicht der Punkt, sondern ob das so geschrieben ist das man sie machen *könnte*. Und gut testbaren Code sollte man immer schreiben, denn spätestens bei der Fehlersuche macht man ja Tests, selbst wenn man die nicht festschreibt und wiederholbar macht — warum eigentlich nicht? Und was hat die Programmlänge damit zu tun? Wobei jetzt auch keiner weiss, wie umfangreich das wird. Du nicht, weil Du von ”lediglich“ 2000 Zeilen ausgehst, was aber relativ ist, weil zwar 2000 Zeilen Python-Code schon ziemlich viel ist, weil Python sehr ausdrucksstark ist. Andererseits bist Du ja noch Anfänger, also sind es vielleicht in Wirklichkeit nur 400 bis 500 Zeilen wenn man die tatsächlich in Python schreibt.
Ich habe so ein bisschen das Gefühl Du kennst die Antwort(en) auf Deine Frage(n) eigentlich schon und versuchst hier nur irgendwie eine Bestätigung zu bekommen, das es irgendwie doch okay sein müsste globale Variablen zu verwenden. Oder nicht so wichtig Code testbar zu schreiben. Oder wenn da keine Not zu besteht das sauber zu trennen auch einen Programmstartzähler in die Settings zu basteln.
Die dynamische Änderung an den Settings ist mir auch nicht klar. Also eigentlich sollten die ja gar nicht geändert werden IMHO, also nicht im Programm. Deine Texte klingen aber teilweise so als wenn die JSON über das Programm verändert werden soll und nicht extern in einem Texteditor wie das IMHO normal wäre. Aber ein Programmstartzähler hat da ja zum Beispiel auch nichts zu suchen. Hatte ich nur nichts zu gesagt weil Du das ja wohl selbst weisst.
Ob Du Unittests machst oder nicht war nicht der Punkt, sondern ob das so geschrieben ist das man sie machen *könnte*. Und gut testbaren Code sollte man immer schreiben, denn spätestens bei der Fehlersuche macht man ja Tests, selbst wenn man die nicht festschreibt und wiederholbar macht — warum eigentlich nicht? Und was hat die Programmlänge damit zu tun? Wobei jetzt auch keiner weiss, wie umfangreich das wird. Du nicht, weil Du von ”lediglich“ 2000 Zeilen ausgehst, was aber relativ ist, weil zwar 2000 Zeilen Python-Code schon ziemlich viel ist, weil Python sehr ausdrucksstark ist. Andererseits bist Du ja noch Anfänger, also sind es vielleicht in Wirklichkeit nur 400 bis 500 Zeilen wenn man die tatsächlich in Python schreibt.
Ich habe so ein bisschen das Gefühl Du kennst die Antwort(en) auf Deine Frage(n) eigentlich schon und versuchst hier nur irgendwie eine Bestätigung zu bekommen, das es irgendwie doch okay sein müsste globale Variablen zu verwenden. Oder nicht so wichtig Code testbar zu schreiben. Oder wenn da keine Not zu besteht das sauber zu trennen auch einen Programmstartzähler in die Settings zu basteln.
„All religions are the same: religion is basically guilt, with different holidays.” — Cathy Ladman