Einstiegsfrage bezüglich Python

[Joghurt]

es ist in einer rein objektorientierten sprache (als was einem python ja immer verkauft wird)

Python ist eine multi-paradigm-Sprache. Imperative, objektorientierte, funktionelle und teilweise auch aspektorientierte Programmierung wird unterstützt.

von daher sollte das implizierte uebergeben von self standard sein.

Das Widerspricht der Python-Philosophie: "explicit is better than implicit"

und eine methode zu deklarieren, die verschiedene arten von eingabedaten akzeptiert und dann eine pruefung auf jede moegliche kombination von typen ist sicher nicht angenehmer, als in einer typisierten sprache eine methode einfach zu ueberladen...

Wenn man sowas macht, versucht man, C++ oder Java in Python zu programmieren und macht etwas falsch. Slange die übergebenen Objekte die benutzen Methoden implementieren, ist es Wurst, von welcher Klasse sie abgeleitet sind. In der Praxis überlädt meine eine Methode ja auch höchstens so:

int foo(int bar, int baz);
int foo(float bar, float baz);
int foo(SupidupiInt bar, SupidupiInt baz);

und nicht so

int foo(int bar, int baz);
int foo(FILE* zieldatei, const char* zu_schreibender_string)

Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests )
Aber du hast recht, ein "Interface"-System wie bei Java wäre ganz nett. Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.

Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.
Als ich mit Python anfingt, hatte ich auch Bedenken ob des "Duck-typing" Ansatzes und den fehlendem private. In der Praxis bringt das aber mehr Vorteile als die theoretischen Nachteile.

wenn ich mir packages wie "_mysql", "PIL" oder auch einige standardmodule anschaue, kann ich das nicht glauben... "StringIO.StringIO"??? wtf...

Ja, das Crux der Rückwärtskompabilität. Ich denke mal, dass wird in Python 3000 auch korrigiert.

[OpOs]

In der Praxis überlädt meine eine Methode ja auch höchstens so:

int foo(int bar, int baz);
int foo(float bar, float baz);
int foo(SupidupiInt bar, SupidupiInt baz);

und nicht so

int foo(int bar, int baz);
int foo(FILE* zieldatei, const char* zu_schreibender_string)

aber diese ueberladung:

collection.add(object)
collection.add(array of object)

macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in python

Und ob nun der Compiler meckert, oder es beim Unittesting auffällt, ist es (ja, ich weiss, nicht jeder schreibt gute unitttests )

mir persoenlich ist es lieber, dass der compiler meckert, als dass ich ein fehlerhaftes und dadurch potenziell verheerendes programm ausfuehre, aber das mag meine persoenliche meinung sein.

Aber so liest man halt die Doku der Methode, um zu sehen, welche Art von Parametern erwartet wird.

dazu muss der entwickler die funktion aber auch entsprechend ausfuehrlich dokumentieren, waehrend es in java bereits aus der deklaration ersichtlich ist und man bei der doku weniger aufwand hat.

Ich programmiere seit einiger Zeit beruflich in Java, und ich muss sagen, die Typdeklaration hat mich bis jetzt nur Zeit gekostet. Einmal hat sie dazui geführt, dass der Compiler meckerte, weil ich zwei Parameter vertauscht hatte, aber das hätte ich in Python auch beim nachfolgenden Test bemerkt.

sei doch froh, dass dich der compiler darauf hingewiesen hat BEVOR du dir eventuell das system kaputt gemacht hast. mag ja sein, dass es nichts gegaehrliches war, aber wird es beim naechsten mal auch so sein...

wie gesagt, ich nutze python auch recht gerne, man muss sich aber im klaren ueber die fallstricke sein!

ich weiss, in c kann man mit dem zeigergefummle geausoviel bockmist machen, aber ich hab ja nich gesagt, dass c das gelbe vom ei iss.

[Joghurt]

aber diese ueberladung:

collection.add(object)
collection.add(array of object)

macht durchaus sinn und ist in java/c++ wesentlich einfacher bzw uebersichtlicher zu implementieren, als in python

In Python würdest du nur die "array of object" Methode definieren. Wenn jemand ein einfaches Objekt hat, macht er einfach beim Aufruf ein Tupel draus:

foo(liste_von_objekten)
foo((einzelnes_objekt,)) # oder foo([einzelnes_objekt])

[Romanday]

Was mich mal interessieren würde:

Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
Welches Problem läßt sich nicht viel schneller mit einer anderen
Programmiersprache lösen?

(Außer die 3D - Ünterstützung habe ich bis jetzt nichts gefunden.)

[RapidMax]

Wo ist der Einsatz von Python zwingend notwendig, sinnvoll.
Welches Problem läßt sich nicht viel schneller mit einer anderen
Programmiersprache lösen?

Der Einsatz von Python ist nur dort zwingen notwendig wo Python vorausgesetzt wird oder Python bereits im Einsatz ist. Und sinnvoll ist es oft, hängt aber mit der jeweiligen Situation ab. Zudem lässt sich jedes Problem mit einer anderen Programmiersprache schneller lösen, vorausgesetzt man nimmt die richtige, andere Programmiersprache.

Diese Antwort dürfte etwas so gummig sein, wie die Frage.

Gruss, Andy

[Romanday]

Diese Antwort dürfte etwas so gummig sein, wie die Frage.

Gruss, Andy

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.

Stichwort: Verbreitungsgrad

Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.
Bis jetzt sehe ich einfach noch keinen Sinn darin in Python tiefer
einzusteigen. Der Reiz fehlt. Ich sehe noch nicht die Vorteile.
Was soll ich damit zusammenbasteln, was es nicht schon in anderen
Sprachen gibt?

[Christoph]

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.

Das stimmt definitiv nicht. Ich setze Python sehr viel ein und habe in den Projekten regelmäßig mit Leuten zu tun, für die Python neu ist. Python ist nach meiner Erfahrung eine der am leichtesten zu lernende Sprache. Verglichen z.B. mit Perl ist die Lesbarkeit um mehrere Größenordnungen besser.

Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.

Python ist weniger für "fertige Apps" geeignet, insbesondere da es ähnlich wie Java eine Runtime-Umgebung braucht, also eine "fertige App" nicht so leicht zu installieren ist. Hauptproblem ist, dass es sich nicht einfach compilieren in ein Executable linken lässt.

Ideal ist es aber für Frameworks für bestimmte Anwendungsbereiche, speziell im wissenschaftlichen Bereich. Und da gibt es interessante "Apps" (z.B. PyLab, Matplotlib oder Gamera).

[Joghurt]

Ich laß mich ja gerne überzeugen, aber bis jetzt sehe ich den
Hauptvorteil in Python das nur wenige User den Code verstehen.

Ich denke, das wurde hier schon widerlegt Der Code ist in der Regel sehr gut verständlich.

Stichwort: Verbreitungsgrad

NASA uses Python...
... so does Rackspace, Industrial Light and Magic, AstraZeneca, Honeywell, and many others

Aus der anderen Seite gibt es leider nicht so eine große Auswahl
an fertigen Apps.

Oh doch, die will ich aber jetzt nicht aufzählen.

Was soll ich damit zusammenbasteln, was es nicht schon in anderen
Sprachen gibt?

Keiner zwingt dich, über den Tellerrand zu schauen. Du kannst deine Programme in C, Basic, Pascal, VB, Java, LISP, Haskell oder was auch immer schreiben.

Hier geht es nicht darum, das/ob Python die beste Sprache ist, die jeder kennen muss; es geht nur darum, zu zeigen, was Pythonprogrammierer an der Sprache schätzen und so anderen eine Entscheidungshilfe zu geben, ob sie sich die Sprache mal anschauen oder es besser lassen.

Wenn du mit deiner aktuellen Sprache glücklich bist, prima! Ich war es nicht, weder mit BASIC, Pascal, C, C++ oder Java. Haskell ist ganz nett, aber mit Python programmiere ich bis jetzt am liebsten. Ich schaue mir immer wieder mal neue Sprache an, bis jetzt gefällt mir Python immer noch am besten.