Das deutsche Python-Forum

Hallo zusammen,

ist mein erstes Post hier. Vor gut einem halben Jahr hab ich begonnen mich mit Python zu befassen und war ziemlich schnell hellauf begeistert und bin es bis heute. Einfach schon, weil es unheimlich viel Spaß macht damit zu arbeiten. Jetzt suche ich nach möglichst handfesten Argumenten für Python, da ich meinen Arbeitgeber überzeugen will, das bei uns in der Firma einzuführen; und sei es nur für mich.

Ich kenne das PDF "Advocating Python", aber ich müsste wohl (oder übel) viel stärker die Vorteile gegenüber anderen Programmiersprachen herausarbeiten, namentlich VB, VBA, C++ und Java, da wir die alle zur Verfügung haben. Ich bin mir sicher, es wird heißen: "nimm doch eine davon!"

Vorweg: dass es kostenlos ist, zählt nicht. Ich hab auch schon ein paar Ideen, wie ich argumentieren könnte, aber ich wollt mal sehen, was Euch so einfällt.

TIA

Greetings!

Bei den Sprachen die Du aufgezählt hast ist keine klassische Skriptingsprache dabei. Vielleicht kenne ich VBA auch zuwenig, aber ich meine sowas wie Perl oder TCL, oder jetzt halt auch Python. Mit denen kann man normalerweise sehr einfach, auf jedenfall einfacher als mit VB, C++ und Java, kleinere Aufgaben rund ums Programmieren erledigen.

Also zum Beispiel einen kleinen Prototyp programmieren oder Testdaten generieren oder Code automatisch generieren usw.

Wenn Du auf irgendein Problem dieser Art oder ähnliches stösst und zeigen kannst, dass das in Python schöner oder schneller als in VBA zu realisieren ist, dann hast Du vielleicht schon ein Argument das zieht.

Hallo

zunächst möchte ich BlackJack mit dem was er sagt recht geben. Aber das ist nur eine Seite der Medaille: Bei einer Firma muß man sich ja sicher auch fragen, ob die Kosten der Einführung (die Zeit, die es braucht, bevor Resultate herauskommen), die Einführung etwas Neuen rechtfertigen.
Python ist toll, aber nicht immer die beste Lösung. Am besten (in meinen Augen) ist es ein Problem zu definieren und sich dann zu fragen welche Sprache(n) es am besten lösen kann / können.
Bruce Eckel hat in "Thinking in C++" ein schönes Kommentar zur Frage geschrieben wie und warum eine Firma am Besten von C nach C++ gehen soll. Mit vielen Pros und Cons. Das Ganze ist auch online erhältllich. (Der betreffende Part steht irgendwo kurz hinter der Einleitung, weiß im Moment nicht wo und bei meiner Verbindung habe ich keine Lust das rauszusuchen - das bleibt an Dir hängen .)

Gruß,
Christian

PS Zu VBA: Ist im Grunde VB, hängt aber von den APIs ab, mit denen es verwendet wird (die meisten nutzen es wohl für Word- oder Excel-Markros). Skriptsprache oder nicht? Ich finde schon ... irgendwie.

Pro

• OpenSource! (ansich schon einige Vorteile gegenüber ClosedSource-Programmierspachen)
  Schnelle Ergebnisse
  gezwungenermassen gut lesbarer code
  module für alle möglichen Probleme vorhanden
  eine Sprache für alle Plattformen
  eine Sprache für Web und lokale Lösungen
  eine Sprache für kleine schnell erstellte Skript-Lösungen für Kommandozeile, aber auch komplexe Grafische Programme möglich

Contra

• bedingt für Preformance lastige Probleme (Auslagern in C)
  nicht geeignet um Kunden ein fertiges Programm zu übergeben, ohne die Sourcen dabei raus zu rücken

Die Liste sollte man vielleicht ins Wiki weiterführen?

jens hat geschrieben:Pro

• OpenSource! (ansich schon einige Vorteile gegenüber ClosedSource-Programmierspachen)

Davon abgesehen ist es Freie Software.

jens hat geschrieben:Contra

• nicht geeignet um Kunden ein fertiges Programm zu übergeben, ohne die Sourcen dabei raus zu rücken

Wieso? Du kannst nur mit pyc oder pyo Dateien laufen, dazu brauchst du die Sourcen nicht. Lassen sich zwar rückwandeln, aber nur in Opcodes, was ja fast wie Assembler ist.

jens hat geschrieben:Die Liste sollte man vielleicht ins Wiki weiterführen?

Klar, nur zu! Die Frage wird ja öfters gestellt.

Leonidas hat geschrieben:

jens hat geschrieben:Contra

• nicht geeignet um Kunden ein fertiges Programm zu übergeben, ohne die Sourcen dabei raus zu rücken

Wieso? Du kannst nur mit pyc oder pyo Dateien laufen, dazu brauchst du die Sourcen nicht. Lassen sich zwar rückwandeln, aber nur in Opcodes, was ja fast wie Assembler ist.

Aber nur fast. Man bekommt nicht nur Opcodes sondern auch wieder Python-Quelltext wenn man es darauf anlegt: http://www.crazy-compilers.com/decompyle/

Wobei ich das jetzt nicht als Gegenargument durchgehen lassen würde. Aus Java-Bytecode kann man auch wieder Java-Quelltext rekonstruieren, die Programme dafür sind im Gegensatz zu decompyle sogar frei erhältlich, und trotzdem wird Java auch im kommerziellen "closed source" Umfeld eingesetzt.

BlackJack hat geschrieben:Aber nur fast. Man bekommt nicht nur Opcodes sondern auch wieder Python-Quelltext wenn man es darauf anlegt: http://www.crazy-compilers.com/decompyle/

Ja, ich kenne decompyle, ich habe sogar alte Quellcodes davon, als es noch frei war. Ich denke aber nicht wirklich, dass das so eine praktikable Lösung ist, hab es aber nicht ausprobiert und dann ist es mir ums Geld doch ein wenig schade Auf der Seite steht aber Now supports Python 2.3, also ist unklar in wie weit die mit Python 2.4 zurecht kommen...

BlackJack hat geschrieben:Wobei ich das jetzt nicht als Gegenargument durchgehen lassen würde. Aus Java-Bytecode kann man auch wieder Java-Quelltext rekonstruieren, die Programme dafür sind im Gegensatz zu decompyle sogar frei erhältlich, und trotzdem wird Java auch im kommerziellen "closed source" Umfeld eingesetzt.

Das Dekompilieren geht sogar sehr einfach, mit Tools wie DJ Java Decompiler.

Was ist etwas schade finde, ist dass es nicht so viele Implementationen von Python gibt, wie bei Java wo es ja Kaffee, Jikes, GCJ usw gibt. Es gibt zwar Jython oder IronPython oder gar PyPy, aber die sind vom vollen CPython Sprachumfang recht weit entfernt. Aber auch das hat vorteile, so weiß man, dass das aktuelle CPython immer die aktuelle Python "Sprache" vollständig versteht.

VBA ist durchaus eine Skriptsprache, aber keine der angenehmen sorten, so ist die Sprache an sich recht unlogisch (zumindest aus Python-Sicht), dass es einmal Set oder wieder Dim oder auch gar nichts zum Variablenzuweisen gibt, gleiches trifft auf VBS zu. Ist jetzt aber auch nicht wirklich ein Handfestes Argument..

Was aber schon eher ein Argument ist, dass du mit dem Programmieren schneller fertig bist, da du dich mehr auf die Aufgabe an sich konzentrieren kannst statt dich mit Zuweisung von Speicher (C, C++) oder durchwälzen der API (Java) aufzuhalten.

Hi N317V

Meine Meinung zu Python.

Vorab: Was hier folgt ist meine rein persönliche Meinung.
Solte ich jemandem in diesem Form zu nahe treten, tut es
mir leid.

PYTONIA ist ein Zustand den ich wie folgt erlebe:

Steigt jemand von einer anderen Sprache auf Python um
und scheut sich nicht einmal eine grössere Anwendung
mit grafischer Oberfläche zu erstellen mit Tkinter,
PMW und PIL als GUI-Erweiterung, wird er nur schwer zur
früheren VOODOO-Sprache zurückkehren.

WICHTIG: Es besteht also die positive Gefahr, dass man
die gewohnte Sprache abhakt.

Python:
-------
Sicher gibt es für bestimmte Anwendungen einen Engpass mit
der Performance. Dieses Problem besteht aber auch bei anderen
Sprachen. Meistens können solche ohnehin nur gelöst werden in-
dem man näher an die Maschine rückt. Das heisst sich als
Mechaniker mit Mr. Assembler verbündet.

Einige Merkmale von Python:
---------------------------

a) Klarer schnell erlernbarer Sprachsyntax, welcher den Namen
Hochsprache verdient.

b) Geschriebene Codabschnitte können sofort und schnell Aus-
getestet werden. Keine zum gähnen anregenden Kompilier- und
Link-Prozesse.

c) Aussagekräftige und gezielte Fehlermeldungen. Nicht Seiten-
lange, manchmal schwer interpretierbare Leitsätze.

d) Zum Editieren braucht es kein VS.... Studio. Es können
normale Editoren verwendet werden die man nach einem Update
nicht wieder neu erlernen muss. (z.B kwrite vi vim)

e) Kleine Codestücke können in der IDLE direkt ausgetestet
werden.

f) Debugen mittels BASH-Shell (Linux) und Printbefehlen.

g) Registry! -> Was ist das?

h) Die geschriebenen Programme arbeiten Stabil. Sie bestehen
aus kleinen Dateien.

i) Programmierfehler können nicht das ganze System zum un-
heilbaren Patienten machen. (worse case: Neuinstallation
des Betriebsystems)

j) Python ist freie Software.

k) Dokumentation ist hervorragend. Teure Bücher, welche nach regel-
mässigen Updates von bestimmten Softwareherstellern obsolete
werden und im Schlunt eines Schweden-Ofens verschwinden, braucht
es fast keine.

l) Der Support ist durch diverse Foren und Modul-Servern gesichert.
Last but not least auch einen Super-Support durch unser Forum.
(free off charge)

k) Vorsicht mit rafinierten Einzeilern. Diese können die Lesbarkeit
eventuell ziemlich beeinträchtigen. Lieber auf mehrere Aussage-
kräftigen Programmzeilen verteilen.

m) Frei von Problemen die bei Updates Geld, Geduld und Motivation
kosten.

n) Die Abhängigkeit von einem oder mehreren Giganten ist minimal.

o) Programme laufen auf allen Plattformen (Linux,Mac,Windows)

usw. usw usw

Es lohnt sich einmal in den Zustand PYTHONIA zu katapultieren.

Gruss wuf

g) und i) haben nichts mit Programmiersprachen zu tun. Die Registry gibts nur unter Windows und ein Programm sollte niemals das komplette System in so einen Zustand bringen dürfen. Diese "Ehre" ist Gerätetreibern und Kernelbugs vorbehalten -- wenn ein Anwendungsprogramm das kann, dann hat das Betriebssystem versagt.

Hallo zusammen,

erstmal vielen Dank für Euer Feedback, hat mir auch schon einige Denkanstöße gegeben. Ich halt Euch auf dem Laufenden. Im Moment siehts ganz gut aus, denke ich. Aber ich will nicht vorschnell urteilen...

Greetings!

Hi Leute,

hat gut geklappt. Der Einsatz von Python wurde mir heute genehmigt. Vielen Dank nochmal für Eure Unterstützung!

Greetings!

Gratuliere und viel Erfolg

lg Leo

Vielleicht kannst du ja hier für die Nachwelt deine Argumente posten.

Nach einem Telefonat mit einem der Entscheider, gab es noch ein paar Punkte zu klären, die ich wie folgt beantwortet hatte:

Lizenz
Python ist kostenlos unter einer Open Source Lizenz erhältlich. Anders als die in diesem Sektor weit verbreitete GPL, erlaubt die PSF-Lizenz von Python sogar die Weitergabe in binärer Form und verlangt nicht die Freigabe des eigenen Quellcodes.

Die Installation von Python ist vorerst nur auf einem oder zwei Entwicklerrechnern vorgesehen.

Anwendungszweck / Ziele
Python soll vor allem im Team Reporting der Kundenbetreuung eingesetzt werden um häufig wiederkehrende Arbeiten zuverlässig automatisieren zu können und schnelle ad hoc Lösungen für spezielle Problemsituationen zu liefern. Die Sprache eignet sich vor allem als eine Art "Kleber" zwischen verschiedenen Applikationen, da sie sich leicht einbinden lässt sowie andere Systeme leicht in Python eingebunden werden können. Unter anderem durch verschiedene Hoch-Level Datentypen und der dynamischen Typisierung bietet sie auch hervorragende Vorraussetzungen für das schnelle Erstellen von voll funktionstüchtigen Prototypen, die dann je nach Performancebedarf ganz oder teilweise in anderen Programmiersprachen wie z.B. C++ reimplementiert werden können, falls nötig. Die syntaktische Nähe von Python zu C++ vermeidet hier doppelte Denkarbeit.

In Python geschriebene Programme sind laut einer Studie der Universität Karlsruhe durchschnittlich doppelt so schnell erstellt und nur halb so lang wie vergleichbare Programme in C, C++ oder Java. Weniger Quellcode bedeutet leichtere Wartung des selben, während die hohe Geschwindigkeit beim Erstellen des Quellcodes hohe Flexibilität verspricht. Vgl. hierzu <http://page.mi.fu-berlin.de/~prechelt/B ... pprtTR.pdf>

Verträglichkeit mit bestehender Software
Unverträglichkeiten mit bestehender Software sind nicht zu erwarten.

Schulung und Support
Anfallender Schulungsbedarf kann intern gedeckt werden. Entsprechende Kenntnisse sind vorhanden. Auf Grund des hohen Levels der Programmiersprache Python kann sie erfahrungsgemäß sehr schnell erlernt werden.

Support kann, wie der Schulungsbedarf, ebenfalls intern erfolgen.

Geplant ist die Einarbeitung eines weiteren Mitarbeiters, der sich bei meiner Abwesenheit oder meinem Ausscheiden um die erstellten Programme kümmert.