Ich kann mich dem, was Blackjack gesagt hat, nur anschließen. Python verfolgt die Philosophie "Der Programmierer weiss am besten, was er tut" sowie der Philosophie von Unittests: "Ungetesteter Code ist kaputter Code".Goswin hat geschrieben:Blackjack: Ich programmiere nicht deshalb in Python, weil Python perfekt ist oder ich es dafür halte. Ich kenne keine perfekte Programmiersprache, und mit einer Haltung wie du sie mir empfiehlst, könnte ich überhaupt nicht programmieren. Natürlich kann z.B. Java besser kapseln, aber dafür hat Java eben andere Nachteile. Nur, die Nachteile von Python wird man als Pythonprogrammierer doch wohl beim Namen nennen dürfen, und auch die beste Methode suchen dürfen, damit zu leben!
"Statische" Sprachen schränken den Programmierer ein, um eine Art von Fehlern zu verhindern. Viele (Logik-)Fehler hingegen können nicht erkannt werden. Für diese braucht man Unittests. Unittests erkennen aber die Art von Fehlern, die der Compiler erkennen kann. gleich mit. Warum also sollte der Compiler überhaupt die Prüfungen durchführen?
Um mal dein Beispiel aufzugreifen, sagen wir es gäbe eine Möglichkeit, "random.seed = 1" zu unterbinden. Dann wäre es doch nur logisch, den Fall abzufangen, dass man "a = foo" schreibt, obwohl man "a = foo()" meinte.
Damit verliert man aber auch die Möglichkeit, Funktionen zu übergeben oder muss dafür eine andere, explizitere Syntax einführen.
Das Problem mit einer "strengen" Sprache ist, dass der Compiler ein paar(!) Fehler erkennt und anmeckert, aber bei weitem nicht alle.
Und dadurch gewinnst du nichts: du musst trotzdem noch einen Unittest schreiben, um die Funktionalität zu testen. Viel schlimmer noch: die (teilweise) Überprüfung durch den Compiler gibt dir ein Gefühl von falscher Sicherheit, dass dich dazu verleiten kann, eben "diesesmal doch keinen Testcase zu schreiben", weil die Funktionalität ja so trivial ist.
In Python hingegen finde ich es ganz praktisch, dass du ein etwas mulmiges Gefühl hast, wenn du Code ohne entsprechenden Unittest schreibst. "Ungetesteter Code ist kaputter Code" ist hier viel offensichtlicher.
Jeder Programmierer hat eine eigene Programmierphilosophie, und wenn deine ist, dass es besser ist, wenn der Compiler dir ein bisschen auf die Finger schaut, dann gibt es genug Sprachen, die diese Philosophie teilen und du mit diesen besser aufgehoben bist! Dass soll nicht heißen, dass Python besser oder schlechter als andere Sprachen ist, sondern nur, dass die Philosophie eine andere ist.
Du bist am produktivsten, wenn du nicht "gegen die Sprache kämpfen" musst, weil sie die Dinge anders sieht als du. Ich z. B. habe dieses Problem bei Sprachen wie C++ und Java, eben weil ich deren Philosophie nicht ganz teile und programmieren in Python fühlt sich für mich eben natürlicher an. Wenn dass bei dir nicht der Fall ist, ist Python für dich wohl nicht die richtige/beste Wahl.
Ich denke dass ist, was Blackjack sagen wollte. (Er kann mich natürlich gerne korrigieren)
Edit (Leonidas): Vom Thread "Klasse mit statischen Attributen ?" abgetrennt.