Python 'Benzingespräche'

[__blackjack__]

Ach wie schön ein allgemeiner `customError` der auch gleiche eine ”custom” Schreibweise für Klassen verwendet, statt die, die alle anderen verwenden. In den meisten gängigen Programmiersprachen.

Nicht das es schon `ValueError` und `TypeError` gäbe, die man verwenden könnte.

Ausnahmen/``raise`` scheinen auch noch nicht so ganz verstanden worden zu sein, wenn danach noch Code steht der niemals ausgeführt werden kann.

Luschtig ist auch „The arguments use is self-explanatory:“, gefolgt von einer Erklärung — ohne die man die Funktion wohl eher nicht verwenden könnte. Komische Vorstellung von „selbsterklärend“.

Der u-Präfix bei dem Docstring macht in Python 3 Code keinen Sinn.

Die Dokumentation erwähnt was von `DEFAULT_SETTINGS` und `data_path`, die beide lokal in der Funktion definiert sind. Solche Implementierungsdetails haben da nichts zu suchen.

Man definiert keine Konstanten in Funktionen.

Super sind auch die Konstanten für die Texte bei den Ausnahmen — nicht das man an der Stelle wo die Ausnahme ausgelöst wird, gleich sehen kann was da für ein Text drin steht, nein, man muss erst an den Anfang der Funktion gehen um den lesen zu können. Andererseits kann man von den Konstanten nicht darauf schliessen welche Texte in Ausnahmen möglich sind, denn es werden gar nicht alle verwendet, die da definiert sind.

Und diese ganzen unnötigen Prüfungen und Meldungen sind auch nur notwendig, weil das alles in einer Funktion steckt die eigentlich mehrere Funktionen erfüllt, statt nur eine.

Kommentar am Anfang sagt das Betriebssystemunabhängigkeit wichtig ist, und dann ist da ein Windowspfad mit \ in der Funktion. Und das dann auch noch völlig unnötig, denn .\dateiname ist das gleiche wie nur der Dateiname. Ob man das aktuelle Arbeitsverzeichnis mit .\ davor setzt oder nicht, macht genau Null Unterschied.

Das nächste Problem in der Richtung kann dann das öffnen einer Datei im Textmodus ohne die Angabe einer Kodierung werden. JSON-Dateien würde ich einfach im Binärmodus öffnen und das `json`-Modul den Rest machen lassen. Ich glaube das schrob ich hier schon mal.

Die Datei mit den Einstellungen wird auch dann geladen wenn man die gar nicht haben will, sondern die Default-Einstellungen erfragt.

Das Schreiben der Einstellungen gibt die auch zurück. Finde ich unerwartet, weil auch unnötig.

Es ist ja auskommentiert, aber: man prüft nur in ganz seltenen Fällen Werte auf ihren Typ und wenn dann auch nicht mit `type()` und ``==``. Damit macht man sich nicht nur das „duck typing“ kaputt, sondern schliesst auch noch alle abgeleiteten Typen aus, was man so selbst in statisch typisierten nicht machen würde.

[ulipy]

@__blackjack__
Danke dir für die umfangreichen, wenn nicht vollständigen Anmerkungen!

Das Meiste von dem, was im code stehenblieb (und nicht "schädlich" für die Funktion war) ist dem Bereich "Übungen" zuzuordnen. Da gibt es sehr Vieles, was "en passant" überprüft, bestätigt und - im Verlauf - verworfen wird.

Die Energie hat wie gesagt nicht ausgereicht - auch nicht zum vollständigen "Putzen"..
Dazu gehören u. a.:
- das "u" als Präfix
- ".\" als Präfix
- Prüfung auf "Typ"
- "code" nach Verwendung von "raise"
(quit() ist überall mit dem Editor problemlos aufzufinden, bei Bedarf auch über mehrere Dateien hinweg - so was kann man sich als Anfänger schnell mal angewöhnen..)

* Klarheit der Trennung von semantischer, syntaktischer, struktureller etc. Ebene(n)
ja, das ist eine bleibene Aufgabe..

* customError
wird wesentlich auch dazu verwendet, um sofort eigene von Parser- oder Interpreter-Meldungen unterscheiden zu können, unabhängig davon, ob Fehlerursachen Python-intern bereits definiert sind

* Konstanten innerhalb Funktionen definieren?
Ok - muss ja nicht sein

* ggfs. Umstellung(en) einzelner Blöcke bzw. Elemente
ja, steht auf der ToDo Liste

* Kompromisse zwischen dem Wunsch nach BS-Unabhängigkeit und der aktuellen Ausrichtung auf Win10
Keine Frage, die sind in unangenehmer Weise vorhanden! Zu einer einheitlichen, BS-unabhängigen Behandlung z. B. des "\" oder "/" bin ich bisher nicht gekommen - steht jedoch nicht an erster Stelle

Entscheidend für mein persönliches Bedürfnis und den Einstieg in die Verwendung der Sprache ist die Problembewusstheit - und die war/ist in vielen Fällen vorhanden, geweckt und geschärft worden - sicher nicht in allen - Überraschungen bleiben mit Sicherheit noch genügend...

Problembewusstheit ist mir das Wichtigste im aktuellen Stadium - Prioritäten ergeben sich dann hauptsächlich aus dem praktischen Bereich.

[ulipy]

@snafu
Ja, ok, bin am arbeiten - Vermengung verschiedener Ebenen..

[ulipy]

Hallo zusammen,
bisher hatte ich ja versucht, etwas komplexere OOP-Objekte so weit eben möglich zu "vermeiden". Selbst die Sprache darüber hängt ja noch gewaltig, nicht zu reden von deren Verwendung..

Spätestens im Zusammenhang mit pathlib ist das nun nicht mehr möglich - hat auch seine Vorteile

Wo finden sich denn für einen Anfänger verwertbare Tips dahingehend, genau wo innerhalb eines Scripts z. B. gewünschte Instanzen definiert und benannt werden? Gibt es dazu leicht nachvollziehbare Regeln?

Die wollen ja für eine Verwendung ggfs. in diversen Funktionen auch wieder leicht im Code aufgefunden werden?
Das würde für mich auf einen Bereich auf Modulebene / Scriptebene hindeuten.

Alternativ wäre vorstellbar, Instanzen genau dort zu definieren, wo sie erstmals benötigt werden - das erscheint mir jedoch nicht sehr sinnvoll - Sucherei und Unsicherheiten wären sicherlich nicht zu verrmeiden.

Was meint ihr?

[__deets__]

Da alles in Python ein Objekt ist, gelten die gleichen Regeln wie fur alles andere: Dinge auf Modul-Ebene sind Konstanten, oder Funktionen/Klassen. Das war es. Argumente werden als parameter reingereicht. Oder sind gegebenenfalls Attribute eines Objektes.

[sparrow]

Und warum muss man objektorientiert Programmieren, wenn man pathlib benutzt?

[narpfel]

@ulipy: Auf `pathlib` bezogen ist der Unterschied zwischen „OOP“ und „nicht OOP“ (`os.path`) im Grunde nichts anderes als dass `os.path` Funktionsaufrufe vom Stil `os.path.foo(filename)` benutzt und `pathlib` vom Stil `filename.foo()`. Soll heißen: Was auch immer du dir da für eine Komplexität einredest, existiert gar nicht.

[ulipy]

Hallo zusammen,
hab evtl. Schwierigkeiten mit dem, was Python "unter der Haube" macht?
Es geht aktuell um temporären import von Funktionen oder Klassen aus Modulen eines snippets-Verzeichnisses.

Irgendwo klemmts..

Code: Alles auswählen

try:
    from import_test import anyfunction
except:
    if not os.path.exists(r'C:\...path...\import_test.py'):
        print('Problem')
        quit()
    print(sys.path)	# output hier OHNE den zusätzlichen Pfad
    sys.path.append(r'C:\...path...\import_test.py')
    print(sys.path)	# output hier MIT zusätzlichem Pfad

    # und hier wird das oben auf "exist" getestete Modul nicht gefunden:
    from import_test import anyfunction
    ===>> ModuleNotFoundError: No module named 'import_test'

"Eigentlich" kann das nur noch an der Art des Aufrufes liegen?

Code: Alles auswählen

from import_test import anyfunction

Fragen über Fragen...

[Sirius3]

Das except ist zu generell. Hier willst Du nur ImportError abfangen. Und statt Problem auszugeben, per `raise` den ImportError weiterhelfen.
sys.path muss den Pfad, in dem das Modul liegt, enthalten.

[__blackjack__]

@ulipy: Du bist glaube ich schon wieder dabei Dich als Anfänger in komplizierte, ”magische”, und mit komischen Überraschungen gespickte Gefilde zu begeben, die in normalen Programmen nix zu suchen haben.