@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
OOP-Entwurfsprinzip auch für Python gültig?
-
- User
- Beiträge: 5
- Registriert: Dienstag 10. Februar 2009, 11:49
"Ich kann nicht allen Menschen helfen!" - Sprach der Engherzige und half keinem.
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?CerebrosuS hat geschrieben: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?
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
Zuletzt geändert von lunar am Donnerstag 12. Februar 2009, 16:39, insgesamt 1-mal geändert.
-
- User
- Beiträge: 5
- Registriert: Dienstag 10. Februar 2009, 11:49
@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
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
"Ich kann nicht allen Menschen helfen!" - Sprach der Engherzige und half keinem.
Der Funktion einen String und keine Zahl übergebenCerebrosuS hat geschrieben: Vll. auch wie man es denn besser machen sollte, da ich leider nichts Anderes gelesen habe bis weilen.
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.
-
- User
- Beiträge: 16
- Registriert: Montag 9. Juni 2008, 18:20
- Kontaktdaten:
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.
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.
Man verflucht die Sprache unendlich. Man stellt sich bei jeder Aufgabenstellung vor: "In Python wär's ein 10-Zeiler, verdammt >_>"...Nagila Hawa hat geschrieben: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.
Wirklich böse, manchmal.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Nagila Hawa hat geschrieben: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.
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.Nagila Hawa hat geschrieben: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.
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- mkesper
- User
- Beiträge: 919
- Registriert: Montag 20. November 2006, 15:48
- Wohnort: formerly known as mkallas
- Kontaktdaten:
Hmm, habe ich noch nie gehört, hast du einen guten Link auf eine Beschreibung?Leonidas hat geschrieben:Generell finde ich es erstaunlich dass Pre&Postconditions sich bisher so wenig durchgesetzt haben, obwohl das Konzept gar nicht so übel ist.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.mkallas hat geschrieben:Hmm, habe ich noch nie gehört, hast du einen guten Link auf eine Beschreibung?
In Python lassen sich die Conditions mit Dekoratoren recht einfach implementieren.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 16
- Registriert: Montag 9. Juni 2008, 18:20
- Kontaktdaten:
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.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Nagila Hawa hat geschrieben:Dadurch nimmt man ihm erstmal auch bestimmte Werkzeuge, aber wenn man sich daran gewöhnt, vermisst man diese Werkzeuge auch nicht
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- User
- Beiträge: 16
- Registriert: Montag 9. Juni 2008, 18:20
- Kontaktdaten:
Funktionale Sprachen sind aber wieder etwas ganz anderes. Das Erstellen und Verwalten von Typen kostet immer zusätzlichen Code.Leonidas hat geschrieben: 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).
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 hat geschrieben: Es ist generell so, dass man Fehler nicht vermeiden kann und davor kann einem auch ein statisches Typsystem nicht ganz retten.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Inwiefern? Typen hast du dort auch und kannst dir ebenfalls deine eigenen definieren.Nagila Hawa hat geschrieben:Funktionale Sprachen sind aber wieder etwas ganz anderes.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice