(Etwas länger weil ich bei einem etwas weiter zurück liegenden Beitrag mit der Antwort angefangen habe. Sorry
)
@NoPy: Das bei `Schreibweise()` passiert mir nicht; soweit kann man den Programmfluss in Python dann schon analysieren, dass mir der Editor hier schon sagt das `RichtigGeschreiben` etwas zugewiesen wird, was aber nie verwendet wird. Ausserdem kommt es selten vor dass ich einen so langen Namen nicht über die Autovervollständigung „schreibe”. Die braucht dazu noch nicht einmal intelligent sein, sondern kann auch einfach nur bereits vorhandene Worte aus dem oder den offenen Dokument(en) vorschlagen. Das heisst wenn ich Schreibfehler in Namen habe, dann üblicherweise sehr konsequent durch das ganze Programm.
Exakt die gleiche Warnung bekomme ich auch in `SetzeWert()`, denn auch dort wird etwas zugewiesen was nicht verwendet wird. Wobei ich als ersten Fehler hier schon das ``x = None`` auf Klassenebene ansehen würde. Das gehört da nicht hin. Da kommen entweder Konstanten hin oder tatsächliche Klassenvariablen. Im ersten Fall würde es `X` — grossgeschrieben — heissen und im zweiten Fall, der *sehr* selten ist, würde man nicht auch auf den Exemplaren ein Attribut mit dem gleichen Namen haben wollen. Das wäre verwirrend.
Die Klasse würde man in Python so schreiben:
Code: Alles auswählen
class IrgendWas(object):
def __init__(self):
self.x = None
Die trivialen Getter/Setter sind unnötige Schreibarbeit. Sollte man irgendwann einmal das Attribut beim Zugriff „berechnen” wollen, ohne Clientcode ändern zu müssen, gibt es `property()` und Dekoratorsyntax.
Wenig überraschend bekomme ich bei `MachWasMitGlobalerVariable()` wieder genau den gleichen Hinweis im Editor, nämlich das eine lokale Zuweisung nicht verwendet wird. Hier ist das eigentliche Problem aber schon einem globalen Namen etwas zuweisen zu wollen. Sehr selten sinnvoll, weil fast immer sauberer lösbar.
Der Kommentar bei `GibGlobaleVariable()` macht keinen Sinn. Was meckert denn Dein System da? Da wird ``global`` überhaupt nicht gebraucht, das verhält sich mit und ohne das Schlüsselwort exakt gleich. Mein Editor meckert mich eher Grundsätzlich an dass dort ``global`` verwendet wird. Eben weil man sich so etwas zwei bis dreimal überlegen sollte ob man wirklich Zustand auf Modulebene haben will.
Das Namen erst zur Laufzeit aufgelöst werden hat nichts mit Compiler oder nicht zu tun. Es gibt auch nach Maschinencode übersetze Sprachen bei denen Namen nicht beim übersetzen gebunden werden. Selbst auf so „low level”-Sprachen wie C trifft das zu, bei dynamisch gebundenen Bibliotheken etwa, da löst der Compiler auch nicht den Funktionsnamen zu einer Adresse auf, und es kann zur Laufzeit passieren, dass das Programm mit einer Meldung aussteigt das eine namentlich genannte Funktion nicht existiert.
Der mittlere Schritt beim Compilieren den Wikipedia angibt — die Zwischendarstellung — ist für einen Compiler nicht zwingend erforderlich. Den gibt es aber beim CPython-Compiler. Der Code wird in einen abstrakten Syntaxbaum übersetzt, bevor daraus der Zielcode generiert wird. Die Module `ast` und `dis` lassen da ein wenig in das „Innenleben” schauen.
Beim Installieren sollte man die Dokumentation lesen was die Module für Abhängigkeiten haben. Das spart einem auch bei statisch kompilierten Sprachen Nerven, denn zum Beispiel ein C- oder C++-Programm immer wieder zu komplilieren bis der erste fehlender Header angemeckert wird, dann die Abhängigkeit zu installieren und wieder bis zum nächsten Compilerfehler und so weiter, ist auch nicht schön. Das Problem mit den Versionsnummern von Bibliotheken hat man dort genau so.
Am besten man verwendet bei einer Linuxdistribution das Paketsystem, oder man verwendet einen Installer der die Abhängigkeiten auflöst, ``pip`` zum Beispiel. Um Python-Projekte mit vielen externen Abhängigkeiten, die man nicht im Python-Package-Index findet und mit ``pip`` & Co installieren kann, würde ich einen Bogen machen.
Irgendwelcher Unsinn lässt sich immer konstruieren. Bei dem Beispiel frage ich mich als erstes warum am Anfang ``test = None`` steht. Und dann würde man das *so* natürlich nicht schreiben sondern so
:
Ich würde ja mal gerne ein *reales* Beispiel sehen wo die Vermeidung durch eine Typdeklaration besser ist als das so umzuschreiben, so das der Fehler auch anders leicht auffällt. Ich frage das deshalb weil mir so etwas sehr selten passiert und dann fast immer weil der Quelltext einfach zu unübersichtlich ist und man den sowieso mal aufräumen/umschreiben sollte. Bei dem gezeigten Beispiel würde man sich ja zum Beispiel fragen warum es überhaupt zwei potentielle Rückgabewerte gibt, die parallel in verzahntem Quelltext entstehen.
Ich frage mich auch wie eine Typdeklaration hier helfen soll. Denn es ist ja ein Fehler im Programmfluss. Wenn man `test` als Zahl deklarieren muss, würde der Fehler *schlechter* auffindbar sein, denn dann könnte man nicht `None` zuweisen sondern würde an der Stelle eine Zahl zuweisen und die Funktion würde anstandslos durchlaufen, aber ein falsches Ergebnis liefert, was potentiell erst viel später auffällt, oder sogar durchrutscht.
``global`` kann man nicht vergessen, man *sollte* es vergessen. Denn modulglobaler Zustand ist unsauber. Damit schafft man sich Zustand und Abhängigkeiten an einer Stelle die kein Python-Programmierer erwartet. Und damit eine unnötige Fehlerquelle und eine Menge „Hä”-Erlebnisse.
Und ``global`` kannst Du einen Namen ja deklarieren. Das macht man mit dem ``global``-Schlüsselwort. Und diese Richtung ist auch genau die richtige, da weniger fehleranfällig. Sonst müsste man nämlich bei jedem neuen Namen auf Modulebene alle lokalen Namen kennen um sicherstellen zu können, dass man nicht ausversehen etwas kaputt macht.
Deine Beispiele für ``global`` überzeugen mich nicht wirklich. Das kann man doch problemlos in einem Objekt kapseln ohne auf so etwas globales zurück zu greifen. Die Funktion die das mal setzt ist dann die `__init__()` und die Funktionen die darauf zurückgreifen sind die Methoden.
Insgesamt habe ich das Gefühl das Du keinen Python-Code schreibst, sondern versuchst eine andere Sprache, zum Beispiel Delphi, möglichst 1:1 in Python-Syntax und Semantik zu pressen. Wenn sich zwei Programmiersprachen nicht sehr ähnlich sind, geht so etwas selten gut.
Aber genau dafür gibt es ja Instrumente wie Unit-Tests.