Hallo Mitnerds,

will mich schon seit ein paar Tagen in Python einarbeiten, kann jedoch noch nicht wirklich erkennen, was daran so überaus toll sein soll. (Sorry für evtl. Fehlschlüsse oder Halbwahrheiten, bin noch ziemlich neu und nubig, was Python angeht)
Klar, die Omnipräsenz von Objekten ist ganz cool, z.B. für Callbacks und so, aber bspw. geht mir dieses "es ist nicht wichtig, zu welcher Klasse ein Objekt gehört, sondern nur, ob es die entsprechenden Methoden enthält" Credo auf den Sack. Ohne Typüberprüfung und co. laufe ich doch immer Gefahr in einen Runtime Error zu geraten. Klar gibts Exceptions und so, aber so richtig wohl fühle ich mich nicht bei dem Gedanken, sowas ständig zur Laufzeit prüfen zu müssen.
Des weiteren scheint es keine Unterscheidung zwischen Privat und Public zu geben, darüber hinaus können Objekteigenschaften überall definiert werden zu können oder täusche ich mich da?
Gleiches gilt für so m. M n. wunderbare Sachen, wie Interfaces und abstrakte Klassen. Klar kann Python Mehrfachvererbung und man kann sich sowas dann quasi per Hand zusammenbasteln. Trotzdem, durch die nicht vorhandene Typprüfung wird das ganze doch etwas ad absurdum geführt, denn ich kann ja nicht überprüfen, ob ein bestimmtes Objekt jetzt ein bestimmtes Interface (bspw. Iterator) implementiert, sondern eben nur, ob die beschissene Methode da ist und das eben erst zur Laufzeit.

Hm also entweder funktioniert die OOP hier ganz anders und ich muss erstmal auf den Geschmack kommen, oder die ganze Sache ist etwas abgefuckt. Kann mich da mal jemand aufklären?

Vielleicht hilft Dir eine "test-driven" Mentalität: Ein erfolgreicher Compilerlauf ist auch nur das bestehen
eines test cases. Bei dynamischen Sprachen wie python muss (sollte) man diesen halt durch
entsprechende Tests ersetzen. Andersrum gesagt: ein statisches Typsystem garantiert Dir auch keine
Abwesenheit von runtime errors.

Exceptions werden in python traditionell sehr liberal verwendet, wenn Dir das nicht schmeckt, ist python
evtl nichts für Dich.

private: lass den Kram, den Du private halten willst, mit 2 underscores beginnen
(self.__so_zum_beispiel), dann kann man von außen nur mit Trix ran.

Interfaces: gibts library-ansätze zu, hab ich jetzt aber auch keine im Kopf.

Was OOP angeht: die Frage "what is an object?" ist gar keine so einfache
Ich finde python genügend OO-ish, vor allem die Metaprogrammierung ist inzwischen recht flauschig.
(Wenn man allerdings abgefahrene Dinge mit dem import system in Kombination mit metaclasses
anstellen will, machts irgendwann dann doch keinen Spaß mehr. Aber das nur am Rande)

summa summarum scheint python Deinen Geschmack nicht so ganz zu treffen, evtl findest Du ja mehr
Freude an C# oder Scala...

Nunja, sagen wir mal, man kann es sich ja nicht immer aussuchen, daher muss ich eben auch mal mit weniger wohlschmeckenden Sprachen zurechtkommen
Was ich mich frage ist, ob denn bei Sprachen, die oben angesprochenen Paradigmen folgen, so Sachen wie Interfaces oder abstrakte Klassen nicht eher überflüssig sind und wenn ja, ob dann einige Designpattern nicht ebenfalls obsolet sind oder umgeschrieben werden müssen. Dabei sind diese Pattern doch eigentlich sprachunabhängig.
Hat mich die Uni jetzt schon zu sehr versaut?

nein. Python wird dich versauen

Einige Design Patterns sind in der Tat nicht wirklich Sprach-unabhängig sondern gehen von Java-Style typed/nondynamic/SI OO aus.

Mit zope.interface gibt es eine relativ populäre Implementierung vom Interface-Konzept für Python though. Und neue versionen kommen mit ABCs (abtstract base classes) built in.

Die nicht-existenz von access-control (public/private/protected) ist ein Feature, das es ja im Grunde bei so ungefähr jeder Sprache gibt, die meisten machen es nur eine Ecke schwerer das zu umgehen. Bei Python gilt (auch in vielen anderen Bereichen, siehe das von dir schon angesprochene 'Duck-typing'): Wir sind hier unter Erwachsenen. Ich teile dir mit, dass diese methode bzw. dieses attribut meiner Klasse nicht zur public API derselben gehört, wenn du also schlau bist wirst du es nicht benutzen (bzw nur wenn es wirklich unbedingt sein muss). (Und Re: Anatol: das name mangling mit 2 underscores ist nicht für private-emulation gedacht sondern um name-clashing bei MI zu vermeiden. sollte man im Grunde nie benutzen. "private" zeigt man iA mit einem underscore an.

Man muss verstehen, dass ich eben an der Uni gesagt kriege, dass sowohl Sichtbarkeiten, als auch Interfaces oder Abstraktion, sowie Typspielereien ultrawichtig sind und quasi der heilige Gral usw. Wenn man damit Frameworks o.ä. gut baut, kann der anwendende Programmierer weniger falsch machen und die Applikation wird stabiler.
Python und co. stellen sowas auf den Kopf. Ich weiß ja, dass einem an der Uni auch jede Menge Blech erzählt wird, aber das ist schon echt krass. Man hat da immer das Gefühl, man wechselt zur dunklen Seite.

Da scheiden sich sicher ein wenig die Geister. Wenn sich die Welt der Informatik da so einig wäre wie du es in der Uni scheinbar mitgeteilt bekommst, gäbe es nicht auf beiden Seiten fähige Leute, die "ihren" Weg für den besseren halten. Und ganz am Rande gibt es gerade in den USA, aber z.B. auch Schweden immer mehr Universitäten, die ihren Studenten Python beibringen.
Meine Erfahrungen mit solchen "dynamischen" Sprachen haben bisher gezeigt, dass das Fehlen all dieser Begrenzungen (Typing, Access Control, usw) das arbeiten im kleinen viel schneller/angenehmer/einfacher macht und im großen (zum Teil wie von Anatol angemerkt durch die Benutzung von Unit Tests) kaum so ein Problem ist, wie man instinktiv gerne annimmt.
Django ist ein gutes Beispiel für ein modernes und mittelmäßig modernes Framework in Python. Und es funktioniert super, ganz ohne all diesen Zwangs-Kram. ;-)
Ein anderes berühmtes Beispiel aus dieser Ecke ist sicher Ruby on Rails, wobei ich persönlich darin auch genau einige der Nachteile der größeren Freiheiten solche Sprachen realisiert sehe. :-)
Unterm Strich kann man wohl nur sagen: Sammel einfach deine eigenen Erfahrungen und schau, wie du damit zurecht kommst. Selbst wenn die Antwort für dich am Schluss heisst "Oha, so ein Mist, gib mir mein Java/C#/Whatever zurück!" heisst, hast du zumindest deinen Horizont erweitert. Und ich finde gerade bei Programmiersprachen und somit unterschiedlichen Ansätzen an das Problemfeld programmieren kann das immer nur gut sein. :-)