OOP-Entwurfsprinzip auch für Python gültig?

[CerebrosuS]

@Dasich

Hm, ...

aber wenn ich doch bsp versuche auf eine Methode eines Objektes zuzugreifen, welche nciht existiert, bekomme ich eine AttributeError Exception.

Und wenn ich von einem Argument einer Funktiion erwarte das es vom Typ str ist und ich "Hallo" + var mache, bekomme ich für type(var) == int bsp. eine TypeError Exception richtig?

Die Funktion bricht unerwartet ab. Erklär mir doch bitte was ich falsch verstanden habe, damit ich drüber nachdenken kann. Vll. auch wie man es denn besser machen sollte, da ich leider nichts Anderes gelesen habe bis weilen.

Grüße

[lunar]

aber wenn ich doch bsp versuche auf eine Methode eines Objektes zuzugreifen, welche nciht existiert, bekomme ich eine AttributeError Exception.

Und wenn ich von einem Argument einer Funktiion erwarte das es vom Typ str ist und ich "Hallo" + var mache, bekomme ich für type(var) == int bsp. eine TypeError Exception richtig?

Wo genau liegt da jetzt der Nachteil? Oder anders gefragt: Wo liegt der Vorteil darin, mittels isinstance den Typ zu überprüfen, und die Ausnahme selbst zu werfen, wenn der Typtest fehlschlägt?

Im Übrigen ist es ja nicht so, dass du der erste Java-Programmierer wärst, der mit dynamischer Typisierung so seine Probleme hat ... die Antworten sind immer die gleichen geblieben => Google, Forumssuche

[DasIch]

Natürlich tritt eine Exception auf aber dass ist selbstverständlich übergebe ich ein Objekt dass sich nicht so verhält wie dass erwartete Objekt.

[CerebrosuS]

@lunar

Danke, ... das war die Frage die mich nachdenken ließ. Ich vergaß, dass ja für Alles eine Exception geworfen wird. Wie Ihr seht, bin ich noch sehr am Anfang und halte mich noch verdammt eng an Java und C/C++ *schäm*

Danke @ lunar und Dasich.

Ich werde direkt mal meinen Code umschreiben und auf effektiveres Exception Handling achten.

Grüße

[Darii]

Vll. auch wie man es denn besser machen sollte, da ich leider nichts Anderes gelesen habe bis weilen.

Der Funktion einen String und keine Zahl übergeben

Worauf DasIch vermutlich hinauswill: Wenn man der Funktion ein Objekt falschen typs übergibt schmiert das ganze schon von alleine ab, da ist keinem mit einer Typprüfung geholfen. Anders sieht es natürlich aus, wenn man aus einer Typprüfung einen Vorteil ziehen könnte. Etwa weil man notfalls eine geeignete Typumwandlung machen kannst (bspw. int -> str) oder um eine aussagekräftigere Fehlermeldung zu werfen.

[Nagila Hawa]

Das Problem, wenn man von einer Sprache mit einem strengen und umfangreichen Typensystem kommt, ist einfach, dass man sich erstmal völlig nackt vorkommt, eines mächtigen Werkzeugs beraubt fühlt und stattdessen lernen muss, die Werkzeuge zu nutzen, die einem Python bietet.

Ich glaube erfahrene Python-Programmierer, die plötzlich mit einer Sprache wie Java oder Ada arbeiten müssen, werden sich auch erstmal gewaltig zurecht finden müssen, weil vieles anders gemacht wird. Und auch hier wird sich wohl als erstes über das Typensystem geärgert, bis man sich daran gewöhnt es richtig und sinnvoll einzusetzen.

Irgendwann reiße ich mich auch mal zusammen und schreibe etwas Größeres in Python, damit ich mich nicht mehr so nackt fühle. Die Prüfungswochen sind ja bald wieder vorbei.

[BlackVivi]

Ich glaube erfahrene Python-Programmierer, die plötzlich mit einer Sprache wie Java oder Ada arbeiten müssen, werden sich auch erstmal gewaltig zurecht finden müssen, weil vieles anders gemacht wird. Und auch hier wird sich wohl als erstes über das Typensystem geärgert, bis man sich daran gewöhnt es richtig und sinnvoll einzusetzen.

Man verflucht die Sprache unendlich. Man stellt sich bei jeder Aufgabenstellung vor: "In Python wär's ein 10-Zeiler, verdammt >_>"...

Wirklich böse, manchmal.

[Leonidas]

Das Problem, wenn man von einer Sprache mit einem strengen und umfangreichen Typensystem kommt, ist einfach, dass man sich erstmal völlig nackt vorkommt, eines mächtigen Werkzeugs beraubt fühlt und stattdessen lernen muss, die Werkzeuge zu nutzen, die einem Python bietet.

Sprichst du von Javas Typsystem? Das "streng und umfangreich" zu nennen würde mir eher weniger in den Sinn kommen. Wenn man ein strenges Typsystem ansehen will dann könnte man Haskell nennen, wenn umfangreich dann Scala. Ich denke der durchschnittliche Java-Programmierer hätte auch damit zuerst mal Probleme obwohl alle genannten Sprachen statisch getypt sind. Es ist einfach anders.

Ich glaube erfahrene Python-Programmierer, die plötzlich mit einer Sprache wie Java oder Ada arbeiten müssen, werden sich auch erstmal gewaltig zurecht finden müssen, weil vieles anders gemacht wird. Und auch hier wird sich wohl als erstes über das Typensystem geärgert, bis man sich daran gewöhnt es richtig und sinnvoll einzusetzen.

Gerade bei Java habe ich öfters das Gefühl das das Typsystem einzig zu dem zweck erfunden wurde um Sachen die in Python einfach sind unter Unmengen von Klassen, Interfaces und Wrappern zu vergraben um irgendwelche Typsicherheit zu erreichen. Ich gebe aber zu dass ich tatsächlich eher ein dynamic-typing-Mensch bin, wenn ich Eingabedaten prüfen will kann ich das viel effektiver mit Preconditions und Postconditions und ggf. Multimethoden machen statt einfach nur naiv zu schauen ob die Typen passen. Generell finde ich es erstaunlich dass Pre&Postconditions sich bisher so wenig durchgesetzt haben, obwohl das Konzept gar nicht so übel ist.

Lustigerweise höre ich eigentlich nie von Haskell-Leuten dass das Typsystem ihnen im Weg steht. Obwohl es viel mehr im Vordergrund steht als in Java.

[mkesper]

Generell finde ich es erstaunlich dass Pre&Postconditions sich bisher so wenig durchgesetzt haben, obwohl das Konzept gar nicht so übel ist.

Hmm, habe ich noch nie gehört, hast du einen guten Link auf eine Beschreibung?

[Leonidas]

Hmm, habe ich noch nie gehört, hast du einen guten Link auf eine Beschreibung?

Da ist eigentlich nicht viel dabei und wenn man so nachdenkt kann man sowas auch trivial selbst erfinden. Hier ein Link der das beschreibt. Der Überbegriff ist Design by Contract, wobei ich von der Nützlichkeit der Invarianten nicht überzeugt bin.

In Python lassen sich die Conditions mit Dekoratoren recht einfach implementieren.

[Nagila Hawa]

Ok, ehrlich gesagt habe ich nicht so viel Ahnung von Java. Ich habe mir nur das System mit den Types und Subtypes kurz angesehen, das vermutlich von Ada stammt. Wie viel davon übernommen wurde und in wie weit man das in Java anwendet, weiß ich allerdings nicht.

Wenn ich in Ada arbeite, weiß ich aber, dass das Typsystem durchaus viel verwendet wird. es steht praktisch nur insofern im Weg, dass man für gewöhnlich einen längeren Code hat.

Nehmen wir mal als Beispiel einen Quaderförmigen Wassertank. Mich interessieren die Seitenlängen und das Fassungsvolumen. Für beides werden beispielsweise gleichartige Fixed-Point-Typen gespeichert. Gleichartig bedeutet normalerweise, dass sie voll kompatibel sind, weil sie die gleichen Eigenschaften besitzen. In Ada allerdings nicht, so dass ich eine Seitenlänge nicht dem Volumen zuweisen kann, was ja auch ein logischer Fehler wäre. Wenn ich aber über die Seitenlängen das Volumen ausrechnen will, kann ich Casten. Du hast also einen Schutz und wenn du den umgehen willst, ist das mit zusätzlichem Code möglich. Du hast aber auf dem ersten Blick sofort die Typen vor dir. Durch die Typen kannst du verschiedene Variablen also logisch voneinander trennen, auch wenn ihre Typen gleiche Eigenschaften besitzen.

Genauso wie die Subranges.

Zum einen ist das eine Sache der Portabilität. Wenn ich auf einem System arbeite, dass mit 16- und 32-Bit-Typen arbeitet und ich eine Zahl brauche, die ganzzahlige Werte von 1 bis 10 speichert, gebe ich dem Compiler diese gewünschten Eigenschaften an. Der Compiler wird daraus einen 16bit-Integer machen. Das ist der kleinste mögliche Typ, der das System voll ausnutzt und alle Eigenschaften bietet, die ich verlange. In einer Sprache mit weniger umfangreichem Typsystem müsste ich selbst einen 16-Bit-Integer verlangen. Wenn ich den Code auf ein System kompiliere, dass nur mit 8 bit, oder nur mit 32 und 64 Bit normal umgehen kann, habe ich ein Problem. Bei Ada wählt der Compiler aber auch hier einen passenden Wert aus. Bei dynamisch typisierten Sprachen wird natürlich ohnehin etwas passendes vom Interpreter verwendet...

Aber auch hier kann man logisch trennen. Wenn ich eine Variable habe, dessen Wertebereich ich zwischen 1 und 100 definiere, weil andere Werte nicht benötigt werden, kann ich einen Fehler in einem anderen Bereich des Systems eventuell dadurch erkennen, dass diese Variable "unlogische" Werte annimmt. Manuelle Rangechecks sind nicht mehr nötig. Nehme ich die obige Wanne wieder und erstelle mir einen anonymen Subtyp, der "Inhalt in Litern" von 0.00 bis 100.00 annimmt, weil in die Wanne nunmal nur 100 Liter reinpassen und alles andere überlaufen würde, diese Wanne auch nicht "leerer als leer" sein kann, habe ich mir sofort die nötige Umgebung geschaffen um auf bestimmte Aktionen logisch reagieren zu können. Man kann sich dadurch zwar auch unnötig vertun (dieses Feature war Schuld am Absturz der Ariane 5 beim Erstflug - man hat Code einfach ungetestet aus der Ariane 4 übernommen und eine "logische Beschränkung des Wertebereichs" hängt natürlich von der Umgebung ab, die sich hier geändert hat), aber im Prinzip bleibt es einfach ein Werkzeug und auch bei manuellen Wertebereichsprüfungen (die man dann übrigens erstmal im Code einzeln suchen muss, was viel Fehlerträchtiger ist...) wäre das passiert.

Wenn ich einen Typ vom anderen ableite kann ich mir auch aussuchen, ob die Typen zueinander kompatibel sein sollen, und in welchem Umfang Operationen auf diesem Typ übernommen oder angepasst werden sollen.

Dass sich der Code aufbläht, wenn man jede einzelne Variable deklarieren muss und sich für alles eigene Typen definiert, für die man dann vermutlich noch generische Pakete instanzieren muss, ist natürlich klar... Es zwingt einem aber niemand dazu. Man kann gerne durch die Bank weg mit den Standardtypen arbeiten. Es wird aber in der Regel nicht gemacht und das hat seinen Grund.


In Python versucht man dem Programmierer Arbeit abzunehmen. Dadurch nimmt man ihm erstmal auch bestimmte Werkzeuge, aber wenn man sich daran gewöhnt, vermisst man diese Werkzeuge auch nicht und freut sich stattdessen über die abgenommene Arbeit. Dass ein und das selbe Programm in Python sehr viel kürzer ausgedrückt werden kann, ist ja kein Geheimnis.

[Leonidas]

Dadurch nimmt man ihm erstmal auch bestimmte Werkzeuge, aber wenn man sich daran gewöhnt, vermisst man diese Werkzeuge auch nicht

Also auf Funktionsebene und zur Laufzeit kannst du das gleiche mit Preconditions erreichen. Typprüfungen sind ja eigentlich nichts anderes als simple Preconditons die eben außer auf Typgleichheit nichts weiter nachprüfen. Ist halt die Frage ob man mehr Flexibilität will, dann braucht man Laufzeitchecks oder oder formale Typkorrektheit und dann kann man statisch typisierte Lösungen nehmen. Aber wenn du so ein Typsystem wie du beschreibst gewöhnt bist, wird dir Java ziemlich primitiv vorkommen.

Apropos statische Typsysteme: Schau dir mal diesen Blogpost an, dem wurde unter anderem eine Haskell-Lösung geschickt, die statisch typisiert ist und trotzdem kompakter als in Python ist (gut, die Performance ist auch untergründig).

Es ist generell so, dass man Fehler nicht vermeiden kann und davor kann einem auch ein statisches Typsystem nicht ganz retten.

[Nagila Hawa]

Apropos statische Typsysteme: Schau dir mal diesen Blogpost an, dem wurde unter anderem eine Haskell-Lösung geschickt, die statisch typisiert ist und trotzdem kompakter als in Python ist (gut, die Performance ist auch untergründig).

Funktionale Sprachen sind aber wieder etwas ganz anderes. Das Erstellen und Verwalten von Typen kostet immer zusätzlichen Code.

Es ist generell so, dass man Fehler nicht vermeiden kann und davor kann einem auch ein statisches Typsystem nicht ganz retten.

Nein, aber jeder Fehler, den man schon zur Compilezeit (bzw bei einer Syntaxprüfung in interpretierten Sprachen) abfangen kann, ist ein Fehler weniger, den man zur Laufzeit finden muss. Je früher man jeweils einen Fehler findet, desto besser. Man kann nicht alle Fehler zur Compilezeit abfangen, aber man sollte versuchen möglichst viele abzufangen.

[Leonidas]

Funktionale Sprachen sind aber wieder etwas ganz anderes.

Inwiefern? Typen hast du dort auch und kannst dir ebenfalls deine eigenen definieren.