Für was nutzt ihr Python?

[Gast]

Ich nutze Python auch überhaupt nicht.

Ich finde Python-Code unglaublich anstrengend zu lesen. Ich hatte mal versucht damit was zu machen und alles in mir hat sich dagegen gewehrt solch einen Code zu schreiben. Es hat sich nicht natürlich für mich an gefühlt. Ich bin halt voll auf den C und C++ Syntax gepolt. Vielleicht bin ich auch zu alt um mich komplett um zu gewöhnen.

[audacia]

So viele Python-Hater hier! Dabei ist es so eine schöne Sprache und ich benutze sie, wann immer ich kann. Wer braucht schon C/C++!

Nein, ich habe dieselben Probleme wie die meisten anderen und würde mich hüten, größere Anwendungen in Python zu schreiben. Für die abstrakte Ebene der Datenverarbeitung mit SciPy/NumPy ist Python ganz okay (was aber mehr mit den Bibliotheken zu tun hat als mit der Sprache), und MatPlotLib ist langsam, erzeugt aber wunderschöne Plots. Aber für größere kommerzielle Projekte mit mehreren Entwicklern und einer Deadline finde ich es ungeeignet.

Vor einiger Zeit habe ich mal das Vergnügen gehabt, mich näher mit zwei größeren Python-Projekten aus der Bildverarbeitung auseinanderzusetzen, was meine Zweifel genährt hat:

• beide GUIs waren furchtbar. Es gibt Qt-Wrapper für Python, und Qt kann sehr brauchbare Ergebnisse erzeugen, aber anscheinend haben Python-Programmierer kein Händchen dafür. Kein Wunder, wenn selbst der Schöpfer der Sprache solche Posts abläßt. "This then, was the big eye-opener for me: that despite all the hype, Windows UI programming is as tedious today as it was in 1995." - Klar, wir schreiben ja alle unsere Message-Loops von Hand; und was bitte ist ein Form-Designer?
• der GIL verhindert fast alle nützlichen Formen von Multithreading. Aber wer braucht das schon, solange Intel alle zwei Jahre eine doppelt so schnelle CPU rausbringt!! Egal, jedenfalls waren die Autoren des einen Programms durchaus der Meinung, daß Multithreading ihnen nützen würde. Was also tun? Separate Worker-Prozesse spawnen und per IPC mit Daten füttern
• fast alle datenverarbeitenden Bibliotheken haben ein C-Backend, weil Python einfach zu langsam ist. Das wäre ja noch kein Problem, aber die meisten nutzen dafür Cython, und das läuft nur zusammen mit CPython. Das ist in der Praxis ein großer Hinderungsgrund, irgendwelche weniger bescheuerten Alternativen wie IronPython zu verwenden: alle Bibliotheken, die Cython verwenden, werden dann nicht unterstützt.
• auch in Python hat der Autor einer Funktion üblicherweise eine genaue Vorstellung davon, welche Argumenttypen er erwartet. Die Folge ist, daß die typische API-Funktion einer Bibliothek zu 3/4 aus manuellen Typ-Assertions besteht. Und das ist guter Library-Code; wenn da keine Typ-Assertions sind, bekommt man irgendwo in den Untiefen der Bibliothek eine obskure Exception. Das ist fast dasselbe Problem wie mit Template-Typargumenten in C++, nur eben zur Laufzeit und ohne Performancevorteil. Außerdem fördert die dynamische Typisierung totum pro parte-Patterns ("dieser Parameter ist die ID des Objekts, aber du kannst auch das Objekt übergeben"), die eine statische Analyse zusätzlich erschweren. Und alles nur für ein paar Zeichen Tippersparnis.
• die Komfort-Nachteile durch das dynamische Typsystem wurden schon erwähnt. Dabei gibt es sogar Tools, die eine Rohform von Code-Completion und sogar Refactorings anbieten (z.B. PTVS); aber es gibt ja sogar eine Python-Implementation ohne GIL (nämlich IronPython), und die benutzt auch keiner. Der wahre Python-Hacker schreibt seinen Code unter Linux im Texteditor (Debugger? Was ist das?), setzt CPython, automake und pip voraus und ist weitgehend kompatibel mit sich selbst.
• natürlich sitzt die Hälfte der Abhängigkeiten noch auf Python 2.7 fest, so daß man selbst kein 3.x verwenden kann.

Klar ist mit Python einfacher anfangen ( print "Hello, World!" ) als mit, sagen wir, C# ( using System; namespace MyProgram { public static class Program { public static void Main(string[] args) { Console.WriteLine("Hello World!"); } } } ). Aber sobald man mal >1000 LoC hat, sind die syntaktischen Fixkosten von C# irrelevant, ganz abgesehen davon, was einem der Tool-Support alles abnimmt ("Generate Method Stub" & "Implement Interface" ftw).

So, jetzt will ich aber mal eine ordentliche Apologie für Python lesen, sonst wird das hier zu einseitig

[TyRoXx]

audacia schrieb:

So, jetzt will ich aber mal eine ordentliche Apologie für Python lesen, sonst wird das hier zu einseitig

- IDEs sind allesamt Bloatware und haben trotzdem nicht alle Features, die bei C-ähnlichen Sprachen sehr sinnvoll wären. Besonders schlimm ist die Situation bei C++, wo IDEs im Jahr 2000 feststecken. Python braucht keine IDE, denn da machen billige Menschen die Fleißarbeit.

- Man kann an einem total kaputten Programm solange Workarounds für Laufzeitfehler einbauen, bis es irgendwie "funktioniert". Das ist in C++ viel schwieriger, weil dabei der Compiler so viele Semantikfehler anmeckert. Außerdem hat C++ undefiniertes Verhalten, was nicht immer ersichtlich ist.

- Python und so sind total hip. Da ist man voll der Hacker ey.

- Alle großen Webseiten laufen mit Python oder Ruby (bis sie das wegwerfen, weil die Hosting-Kosten explodieren).

- Python kann man als besseres Bash verwenden.

- Python ist besser als PHP.

- Mit der Aussprache Pyfon kann man Pedanten ärgern, die wissen, dass der Name nicht von der Schlange kommt.

[Shade Of Mine]

TyRoXx schrieb:

- IDEs sind allesamt Bloatware und haben trotzdem nicht alle Features, die bei C-ähnlichen Sprachen sehr sinnvoll wären. Besonders schlimm ist die Situation bei C++, wo IDEs im Jahr 2000 feststecken. Python braucht keine IDE, denn da machen billige Menschen die Fleißarbeit.

Gute IDEs sparen soviel Zeit, ich muss jedesmal lachen wenn Jemand einen normalen Texteditor verwendet...

[dot]

Shade Of Mine schrieb:

TyRoXx schrieb:

- IDEs sind allesamt Bloatware und haben trotzdem nicht alle Features, die bei C-ähnlichen Sprachen sehr sinnvoll wären. Besonders schlimm ist die Situation bei C++, wo IDEs im Jahr 2000 feststecken. Python braucht keine IDE, denn da machen billige Menschen die Fleißarbeit.

Gute IDEs sparen soviel Zeit, ich muss jedesmal lachen wenn Jemand einen normalen Texteditor verwendet...

http://www.pequenocerdocapitalista.com/wp-content/uploads/2012/09/The_Sarcasm_Misunderstanding_by_ThePlotThinnens.jpg :p

[Ethon]

Shade Of Mine schrieb:

TyRoXx schrieb:

- IDEs sind allesamt Bloatware und haben trotzdem nicht alle Features, die bei C-ähnlichen Sprachen sehr sinnvoll wären. Besonders schlimm ist die Situation bei C++, wo IDEs im Jahr 2000 feststecken. Python braucht keine IDE, denn da machen billige Menschen die Fleißarbeit.

Gute IDEs sparen soviel Zeit, ich muss jedesmal lachen wenn Jemand einen normalen Texteditor verwendet...

sprachabhängig.
Aber zB Java würde mich ohne Eclipse ziemlich nerven, mit Eclipse aber geschmeidig.

[Gast]

TyRoXx schrieb:

Ethon schrieb:

Nichts Größeres weil mich da das fehlende (explizite) Typsystem furchtbar nervt, ich finde Programmieren ohne Typen sehr schwierig.

Solche Sprachen haben genau einen Typ.

Für winzige Programme, die in lesbarer Schrift auf den Bildschirm passen, kann ich gerade so noch mit Lua leben. Ich kann mir aber nicht vorstellen wie man damit größere Programme schreiben kann. Auf der Arbeit musste ich mal einen Bug in einer wenige hundert Zeilen umfassenden Javascript-Datei für eine Webseite beheben. Das ist wahnsinnig schwierig, wenn man eine IDE und einen Compiler gewohnt ist, die ein sinnvolles Typsystem unterstützen und damit ganz viel Unsinn vor dem Ausführen finden. Was kann in diesem Argument alles hereinkommen? In einer vernünftigen Sprache ist diese Frage schnell beantwortet, denn es steht direkt in der Parameterliste. In so einer Schwachsinnssprache wie Javascript muss man dann alle Aufrufe heraussuchen und hoffen, dass man keinen übersehen hat. Etwas umbenennen oder einen Parameter hinzufügen? In einer vernünftigen Sprache ganz einfach, weil dann bei jeder Verwendung der Compiler einen Fehler meldet. In ach so flexiblen "dynamischen" Sprachen ist so etwas Einfaches der Horror.

Da muss es einen tollen Vorteil geben, der den gewaltigen Produktivitätsverlust beim Herumsuchen ausgleicht. Kann mich mal jemand aufklären?

php ist mir sympathischer und Zeilenumbrüche statt 10000 Buchstaben in einer Zeile ebenfalls.

EDIT:
Hat was mit Gedanken sortieren zu tun

[krümelkacker]

Ich hab’ Python mal gelernt, weil ich dachte, dass das praktisch für mich wär’. Aber im Endeffekt nutze ich die Sprache jetzt nicht. Im Moment experimentiere ich eher mit Rust, habe aber auch ein Auge auf Julia geworfen. Julia find ich interessant als Ersatz für Python / Matlab / GNU Octave, weil es generische Programmierung anscheinend besser unterstützt (Yay multiple dispatch!) und weil es JIT-kompiliert wird und daher nicht so lahmarschig ist.

Oh warte ... mir fällt gerade ein, dass ich ja doch was in Python gebastelt habe, was ich sogar hinterher benutzt habe: Ich hab’ mich per Python in den DBus reingehängt, um in Abhängigkeit von Pidgin-Benachrichtigungen eine per USB angeschlossene RGB-LED anzusteuern — als Ersatz für die akkistuschen Signale.

[Gast]

Weil hier das Thema IDE so extensiv angesprochen wird: Ich war bisher auch mit keiner Python-IDE richtig glücklich, inklusive des heiligen ERIC - bis ich durch Zufall das Python-Plugin für KDevelop entdeckt habe. KDevelop + Python-Plugin ist für mich durchaus vergleichbar mit Eclipse für Java.

[Gast]

PyCharme ist auch sehr gut.

[Marthog]

SeppJ schrieb:

Ich weiß gar nicht mehr, was mich konkret störte, ich glaube es war irgendwas mit dem Objektmodell und/oder der Typisierung.

Das Objektmodell ist schlimm. Man gibt naemlich keine richtige Klassendefinition, sondern nur ein paar Methoden. (Member-)Variablen setzt man per Zuweisung, wodurch man die Member im idealfall alle im Konstruktor stehen hat, sie aber auch in irgendwelchen anderen Funktionen gesetzt werden koennen. Das fuehrt aber dazu, dass man bei falsch geschriebenen Variablennamen eine neue Variable anlegt, bei vergessenem self (der this-pointer) eine lokale Variable anglegt oder man einfach vergessen kann, eine Variable zu setzen, und alle Fehler erst zur Laufzeit beim Zugriff ausgeloest werden und dann auch noch in irgendwelchen Unterfunktionen von Unterfunktionen.

[audacia]

Aus aktuellem Anlaß: was macht folgender Code?

def f(a):
  def g():
    print a
  return g
f(42)()

Klar, gibt 42 aus. Und was macht das hier?

def f(a):
  def g():
    print a
    a = 0
  return g
f(42)()

UnboundLocalError: local variable 'a' referenced before assignment

Python ist auf so viele Weisen kaputt, ich weiß gar nicht, wo anfangen

Workaround in Python 3 ist mit nonlocal möglich, in Python 2.7 gar nicht. Der übliche Vorschlag ist, daß man in f ein Dictionary anlegen soll, in das man dann in g reinschreiben kann.

[Shade Of Mine]

Wobei ich das jetzt nicht so tragisch finde. Es gibt viel magic mit Variablen, die tut meistens das passende - aber halt leider nicht immer.

Das implizite deklarieren von Variablen ist manchmal halt doof.

Prinzipiell einfach keine Zuweisungen an Argumente machen

Ich bevorzuge folgende Lösung:

def f(a):
  a=[a]
  def g():
    print a[0]
    a[0] = 0
  return g
f(42)()

oder

def f(a):
  f.a=a
  def g():
    print f.a
    f.a = 0
  return g
f(42)()

Oder aber direkt gleich eine Klasse statt einer Funktion nehmen

class fClass(object):
  def __init__(self,a):
    self.a=a
  def __call__(self):
    print self.a
    self.a=0

fClass(42)()

Aber klar, automagische Sachen können manchmal nervig sein und variablen deklarationen wären in der Tat sehr praktisch.

[audacia]

Shade Of Mine schrieb:

Prinzipiell einfach keine Zuweisungen an Argumente machen

Mit einer lokalen Variable von f hättest du dasselbe Problem.

Shade Of Mine schrieb:

def f(a):
  f.a=a
  def g():
    print f.a
    f.a = 0
  return g
f(42)()

Schön, das kannte ich noch nicht, und das werde ich benutzen. Danke!

[Shade Of Mine]

audacia schrieb:

Shade Of Mine schrieb:

def f(a):
  f.a=a
  def g():
    print f.a
    f.a = 0
  return g
f(42)()

Schön, das kannte ich noch nicht, und das werde ich benutzen. Danke!

Achtung, a ist dadurch "public property" von f. Und du kannst
print f.a
auch außerhalb von f machen.

[Bengo]

Phyton ist für mich maximal für ein mathematisches script interessant, weil Dinge wie Mengen und Complexe zahlen direkt in der Sprache sind.
Phython für etwas produktives einzusetzen fällt mir hoffentlich nicht in meinem schlimmsten Alptraum ein. (Es sei denn ich möchte jemanden verarschen)

Das mag subjetiv sein, aber es gibt auch ohne Ende objektive Gründe, die hier bestimmt schon genannt wurden.

[audacia]

Shade Of Mine schrieb:

Achtung, a ist dadurch "public property" von f.

Das wird ja immer schlimmer Die Syntax sah für mich aus wie eine explizite Scoping-Methode. Aber wozu soll das mit den Funktions-Membern gut sein? Für diesen Anwendungsfall gibts doch class .

Allerdings hat Python eh ein gestörtes Verhältnis zur Kapselung. Konstanten und Variablen innerhalb eines Moduls sind ja auch unweigerlich public, und private Funktionen definieren ist nicht vorgesehen. Und das Lustigste ist, wenn man auf Stackoverflow fragt, was der Blödsinn soll, bekommt man nur you're holding it wrong zur Antwort. "Python drops that pretence of security and encourages programmers to be responsible."

Ich nehme dann jedenfalls eine lokale Klasse und wundere mich weiterhin, warum so viele nützliche Bibliotheken gerade für diese Sprache geschrieben werden mußten.

[SLx64]

krümelkacker schrieb:

Julia find ich interessant als Ersatz für Python / Matlab / GNU Octave, weil es generische Programmierung anscheinend besser unterstützt (Yay multiple dispatch!) und weil es JIT-kompiliert wird und daher nicht so lahmarschig ist.

Ich hoffe auch, dass die Entwicklung von Julia schneller voran geht und man die Sprache stabil für alles nutzen kann. Gerade die Geschwindigkeit und die super Unterstützung für viele mathematische Operationen ist genial.

Für kleinere Skripte wäre Python eigentlich super und ich finde die große Unterstützung durch so viele Bibliotheken und die große Community super. In meinem Bereich findet Python auch leider sehr viel Verwendung. Es stören mich aber ein paar Dinge an Python:

- Einrücken für Code-Blöcke
- ziemlich langsam
- 2.x-irgendwas hauptsächlich genutzt und 3.x eigentlich die neuste Version

Die Inkompatibilität zwischen den Versionen und dann noch diese ganzen unterschiedlichen Interpreter, die irgendwas aber nie alles unterstützen, kombiniert mit "white space statt Klammern oder begin/end" und die weniger gute Performance schrecken mich persönlich ziemlich von Python ab.

Meine bisher einzigen Alternativen sind Lua (viel genutzt aber sehr schlechte Ressourcen), Javascript (node.js ist ganz cool aber Javascript ist bei Desktop-Anwendungen eher zum skripten von GUIs geeignet und hat dafür aber schlechte Mathe- und I/O-Unterstützung) und Julia. Letzteres kombiniert die Stärken von Python mit einer angenehmeren Synthax und besserer Perfomance, ist aber noch zu jung und nicht weit genug entwickelt/angenommen. Ansonsten wäre es genau das, was ich brauche.

[Shade Of Mine]

audacia schrieb:

Shade Of Mine schrieb:

Achtung, a ist dadurch "public property" von f.

Das wird ja immer schlimmer Die Syntax sah für mich aus wie eine explizite Scoping-Methode. Aber wozu soll das mit den Funktions-Membern gut sein? Für diesen Anwendungsfall gibts doch class .

Weil Funktionen auch nur Objekte sind

Allerdings hat Python eh ein gestörtes Verhältnis zur Kapselung. Konstanten und Variablen innerhalb eines Moduls sind ja auch unweigerlich public, und private Funktionen definieren ist nicht vorgesehen.

Ja, es gibt keine access privileges. Das hat vor und nachteile. Ich habe beruflich viel mit JavaScript zu tun, das hat das auch nicht, bietet aber moeglichkeiten an den Zugriff zu unterbinden in dem die Sichtbarkeit weggenommen wird.

Meine Python Projekte waren aber nie so gross dass es notwendig war hier wirklich hart zu kapseln. Aber vermutlich gehen die selben Tricks wie in JavaScript auch in Python - indem man die Sichtbarkeit unterbindet.

Ich nehme dann jedenfalls eine lokale Klasse und wundere mich weiterhin, warum so viele nützliche Bibliotheken gerade für diese Sprache geschrieben werden mußten.

Ach, ich finde Python ganz angenehm. Ich finde aber eher die Libraries furchtbar designed. Die sind zwar teilweise enorm praktisch, aber das Design ist zum grausen

Wofuer verwendest du Python denn?
Ich schreibe damit eigentlich nur System Maintenance Scripte.

[audacia]

Shade Of Mine schrieb:

Weil Funktionen auch nur Objekte sind

D.h., class ist nur Syntaxzucker, und eigentlich ist Python wie Javascript? WTF.

Nein, ich weiß schon, daß class mehr kann. Aber trotzdem, das kommt davon, wenn jemand everything is an object zu wörtlich nimmt und nicht weiß wozu.

Shade Of Mine schrieb:

Ach, ich finde Python ganz angenehm.

Ja, wie gesagt, für Hello-world-Projekte ist es supereinfach, und als Taschenrechner on steroids auch gut geeignet dank NumPy. Und halt zum Plotten, weil MatPlotLib einfach schöne Plots erzeugt. Aber schon als Taschenrechner fand ich R schöner. Nur ist das leider nochmal eine Größenordnung langsamer.

Shade Of Mine schrieb:

Ich finde aber eher die Libraries furchtbar designed. Die sind zwar teilweise enorm praktisch, aber das Design ist zum grausen

Kein Wunder, wenn die Sprache genauso ist.

Shade Of Mine schrieb:

Wofuer verwendest du Python denn?

Wissenschaftliches Rechnen. Das Numbercrunchingzeug mache ich in C++ (oder Fortran, wenn es da noch überlieferten Code gibt), und für High-level-Ablaufssteuerung und zum Plotten benutze ich eben Python. Hauptgrund ist, daß a) hier alle das benutzen und b) MatPlotLib gute Ergebnisse produziert. Dank PTVS ist das cross-language debugging relativ schmerzlos. Aber die Sprache macht mich trotzdem regelmäßig schaudern.

Früher hab ich auch mal an einem Bildverarbeitungsprojekt gearbeitet, das Python benutzte. Mein voriger Post zum Thema beschreibt meine Eindrücke davon. Damals habe ich auch mit Python for .NET rumgespielt, was eine recht angenehme Brücke zwischen CPython und .NET zu sein versprach. Leider hat das in komplexeren Projekten nie fehlerfrei funktioniert, so daß ich angesichts meiner Deadline das gemacht habe, was Pythonprogrammierer immer machen: meine Programmbestandteile in verschiedene Prozesse zerlegt, die über Kommandozeilenargumente und Dateien interagieren

Julia beobachte ich auch mit Interesse. Ein, zwei Jahre soll es noch reifen, dann sehe ichs mir mal näher an.