Was sind die Nachteile von Python? [geschlossen]

Python scheint heutzutage der letzte Schrei zu sein, und das nicht ohne Grund - denn es ist wirklich eine Sprache, mit der man gerne ein neues Problem löst. Aber, wie ein weiser Mann einmal sagte (nenne ihn nur einen weisen Mann , weil ich keine Ahnung habe, wer es tatsächlich sagte; nicht sicher, ob er überhaupt so weise war), um eine Sprache wirklich zu beherrschen, kennt man nicht nur ihre Syntax, Design usw., Vorteile, aber auch Nachteile. Keine Sprache ist perfekt, manche sind einfach besser als andere.

Also, was wären Ihrer Meinung nach objektive Nachteile von Python.

Hinweis: Ich bitte hier nicht um einen Sprachvergleich (dh C # ist besser als Python, weil ... yadda yadda yadda) - eher eine objektive (bis zu einem gewissen Grad) Meinung, welche Sprachfunktionen schlecht gestaltet sind, ob, was vielleicht einige fehlen dir und so weiter. Sie müssen eine andere Sprache als Vergleich verwenden, aber nur, um einen Punkt zu veranschaulichen, auf den sonst nur schwer einzugehen wäre (dh um das Verständnis zu erleichtern).

Ich benutze Python ziemlich regelmäßig und halte es insgesamt für eine sehr gute Sprache. Trotzdem ist keine Sprache perfekt. Hier sind die Nachteile in der Reihenfolge ihrer Bedeutung für mich persönlich:

1. Es ist langsam. Ich meine wirklich sehr, sehr langsam. Häufig spielt dies keine Rolle, aber es bedeutet definitiv, dass Sie für diese leistungskritischen Elemente eine andere Sprache benötigen.

2. Verschachtelte Funktionen haben den Nachteil, dass Sie keine Variablen im äußeren Bereich ändern können. Bearbeiten: Ich verwende aufgrund der Bibliotheksunterstützung immer noch Python 2, und dieser Designfehler irritiert mich, aber anscheinend ist er in Python 3 aufgrund der nicht- lokalen Anweisung behoben . Ich kann es kaum erwarten, dass die von mir verwendeten Bibliotheken portiert werden, damit dieser Fehler endgültig auf den Aschehaufen der Geschichte geschickt werden kann.

3. Es fehlen ein paar Funktionen, die für Bibliotheks- / generischen Code nützlich sein können, und IMHO ist die Einfachheit, die zu ungesunden Extremen führt. Die wichtigsten, an die ich denken kann, sind benutzerdefinierte Werttypen (ich vermute, diese können mit Metaklassen-Magie erstellt werden, aber ich habe es noch nie versucht) und ref-Funktionsparameter.

4. Es ist weit vom Metall entfernt. Müssen Sie Threading-Primitive oder Kernel-Code schreiben oder so? Viel Glück.

5. Obwohl es mir nichts ausmacht, dass ich semantische Fehler nicht im Voraus abfangen kann, um die Dynamik, die Python bietet, in Abrede zu stellen, wünschte ich mir, es gäbe eine Möglichkeit, syntaktische Fehler und dumme Dinge wie die falsche Eingabe von Variablennamen abzufangen, ohne den Code tatsächlich ausführen zu müssen.

6. Die Dokumentation ist nicht so gut wie Sprachen wie PHP und Java, die einen starken Rückhalt im Unternehmen haben.

Ich hasse es, dass Python nicht zwischen Deklaration und Verwendung einer Variablen unterscheiden kann. Sie brauchen keine statische Eingabe, um dies zu erreichen. Es wäre einfach schön zu sagen, dass dies eine Variable ist, die ich absichtlich deklariere, und ich beabsichtige , einen neuen Namen einzuführen, dies ist kein Tippfehler.

Darüber hinaus verwende ich Python-Variablen normalerweise in einem einmal beschreibbaren Stil, dh, ich behandle Variablen als unveränderlich und ändere sie nicht nach ihrer ersten Zuweisung. Dank Funktionen wie dem Listenverständnis ist dies eigentlich unglaublich einfach und der Codefluss ist leichter zu verfolgen.

Ich kann diese Tatsache jedoch nicht dokumentieren. Nichts in Python hindert mich daran, Variablen zu überschreiben oder wiederzuverwenden.

Zusammenfassend möchte ich zwei Schlüsselwörter in der Sprache haben: varund let. Wenn ich in eine Variable schreibe, die von keiner dieser Variablen deklariert wurde, sollte Python einen Fehler auslösen. Außerdem letdeklariert Variablen als schreibgeschützt, während varVariablen "normal" sind.

Betrachten Sie dieses Beispiel:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Beachten Sie, dass die Typen immer noch implizit sind ( letVariablen sind jedoch in jeder Hinsicht statisch typisiert, da sie nicht auf einen neuen Wert zurückgeführt werden können, während varVariablen möglicherweise weiterhin dynamisch typisiert werden).

Schließlich sollten alle Methodenargumente automatisch let, dh schreibgeschützt sein. Es gibt im Allgemeinen keinen guten Grund, einen Parameter zu ändern, mit Ausnahme der folgenden Redewendung:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Dies könnte durch eine etwas andere Redewendung ersetzt werden:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

Meine Hauptbeschwerde ist das Threading, das unter vielen Umständen (im Vergleich zu Java, C und anderen) aufgrund der globalen Interpretersperre nicht so performant ist (siehe "Inside the Python GIL" (PDF-Link) talk).

Es gibt jedoch eine Multiprozess-Schnittstelle , die sehr einfach zu verwenden ist. Sie wird jedoch die Speichernutzung für die gleiche Anzahl von Prozessen im Vergleich zu Threads erhöhen oder schwierig sein, wenn Sie viele gemeinsame Daten haben. Der Vorteil ist jedoch, dass ein Programm, das mit mehreren Prozessen arbeitet, über mehrere Computer skaliert werden kann, was mit einem Thread-Programm nicht möglich ist.

Ich bin mit der Kritik an der Dokumentation wirklich nicht einverstanden, ich denke, sie ist ausgezeichnet und besser als die meisten, wenn nicht alle wichtigen Sprachen.

Außerdem können Sie viele der Laufzeitfehler, auf denen pylint ausgeführt wird, abfangen .

Das Fehlen einer statischen Typisierung, die zu bestimmten Klassen von Laufzeitfehlern führen kann, ist die zusätzliche Flexibilität, die die Duck-Typisierung bietet, wohl nicht wert.

Ich denke, die objektorientierten Teile von Python fühlen sich irgendwie "angeschraubt" an. Das gesamte Erfordernis, "self" explizit an jede Methode weiterzugeben, ist ein Symptom dafür, dass die OOP-Komponente nicht ausdrücklich geplant war. Es zeigt auch Pythons manchmal kritische Regeln, die in einer anderen Antwort kritisiert wurden.

Bearbeiten:

Wenn ich sage, dass sich Pythons objektorientierte Teile "angeschraubt" anfühlen, meine ich, dass sich die OOP-Seite manchmal eher inkonsistent anfühlt. Nehmen wir zum Beispiel Ruby: In Ruby ist alles ein Objekt, und Sie rufen eine Methode mit der bekannten obj.methodSyntax auf (natürlich mit Ausnahme überladener Operatoren). in Python ist auch alles ein Objekt, aber einige Methoden, die Sie als Funktion aufrufen; Das heißt, Sie überladen __len__eine Länge, um sie zurückzugeben, nennen sie aber len(obj)statt der bekannteren (und konsistenteren) obj.lengthin anderen Sprachen. Ich weiß, dass es Gründe für diese Designentscheidung gibt, aber ich mag sie nicht.

Darüber hinaus fehlt dem OOP-Modell von Python jeglicher Datenschutz, dh es gibt keine privaten, geschützten und öffentlichen Mitglieder. Sie können sie mit _und __vor Methoden imitieren , aber es ist irgendwie hässlich. In ähnlicher Weise ist Python nicht ganz bekommt den Message-Passing - Aspekt des OOP Rechts, auch nicht .

Dinge, die ich an Python nicht mag:

1. Threading (Ich weiß, es wurde bereits erwähnt, aber erwähnenswert in jedem Beitrag).
2. Keine Unterstützung für mehrzeilige anonyme Funktionen ( lambdakann nur einen Ausdruck enthalten).
3. Fehlen einer einfachen, aber leistungsstarken Eingabelesefunktion / -klasse (wie cinoder scanfin C ++ und C oder Scannerin Java).
4. Alle Zeichenfolgen sind nicht standardmäßig Unicode (sondern in Python 3 behoben).

Standardargumente mit veränderlichen Datentypen.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

Es ist normalerweise das Ergebnis einiger subtiler Fehler. Ich denke, es wäre besser, ein neues Listenobjekt zu erstellen, wenn ein Standardargument erforderlich wäre (anstatt ein einzelnes Objekt für jeden Funktionsaufruf zu erstellen).

Bearbeiten: Es ist kein großes Problem, aber wenn in den Dokumenten auf etwas verwiesen werden muss, bedeutet dies in der Regel, dass es ein Problem ist. Dies sollte nicht erforderlich sein.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Vor allem, wenn das der Standard sein sollte. Es ist nur ein seltsames Verhalten, das nicht mit dem übereinstimmt, was Sie erwarten, und das für eine große Anzahl von Umständen nicht nützlich ist.

Einige der Funktionen von Python, die es als Entwicklungssprache so flexibel machen, werden auch als Hauptnachteil der statischen Analyse angesehen, die beim Kompilieren und Verknüpfen in Sprachen wie C ++ und Java durchgeführt wird.

• Implizite Deklaration lokaler Variablen

Lokale Variablen werden mit der normalen Zuweisungsanweisung deklariert. Dies bedeutet, dass Variablenbindungen in einem anderen Bereich eine explizite Annotation erfordern, die vom Compiler abgerufen werden muss (globale und nicht lokale Deklarationen für äußere Bereiche, Attributzugriffsnotation für Beispielbereiche). Dies reduziert die Anzahl der für die Programmierung erforderlichen Boilerplates erheblich, bedeutet jedoch, dass statische Analysetools von Drittanbietern (z. B. Pyflakes) erforderlich sind, um Prüfungen durchzuführen, die vom Compiler in Sprachen ausgeführt werden, die explizite Variablendeklarationen erfordern.

• "Monkey Patching" wird unterstützt

Der Inhalt von Modulen, Klassenobjekten und sogar des eingebauten Namespaces kann zur Laufzeit geändert werden. Dies ist enorm leistungsfähig und ermöglicht viele äußerst nützliche Techniken. Diese Flexibilität bedeutet jedoch, dass Python einige Funktionen nicht bietet, die für statisch typisierte OO-Sprachen typisch sind. Insbesondere ist der Parameter "self" für Instanzmethoden eher explizit als implizit (da "Methoden" nicht in einer Klasse definiert werden müssen, können sie später durch Ändern der Klasse hinzugefügt werden, was bedeutet, dass dies nicht besonders praktisch ist implizite Übergabe der Instanzreferenz) und Attributzugriffskontrollen können nicht ohne weiteres erzwungen werden, je nachdem, ob sich der Code "innerhalb" oder "außerhalb" der Klasse befindet (da diese Unterscheidung nur während der Ausführung der Klassendefinition besteht).

• Weit weg vom Metall

Dies gilt auch für viele andere Hochsprachen, aber Python tendiert dazu, die meisten Hardwaredetails zu abstrahieren. Systemprogrammiersprachen wie C und C ++ eignen sich noch weitaus besser für den direkten Hardwarezugriff (Python kann jedoch problemlos über CPython-Erweiterungsmodule oder portabler über die ctypesBibliothek mit diesen kommunizieren ).

1. Verwenden von Einrückungen für Codeblöcke anstelle von {} / begin-end.
2. Jede neuere moderne Sprache hat einen angemessenen lexikalischen Geltungsbereich, aber nicht Python (siehe unten).
3. Chaotische Dokumente (vergleiche mit der hervorragenden Perl5-Dokumentation).
4. Zwangsjacke (es gibt nur einen Weg).

Beispiel für defektes Scoping; Abschrift der Dolmetschersitzung:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globalund nonlocalSchlüsselwörter sind eingeführt worden, um diese Entwurfsdummheit zu bessern.

Ich finde Pythons Kombination aus objektorientierter this.method()und prozeduraler / funktionaler method(this)Syntax sehr beunruhigend:

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Dies ist besonders schlimm, da eine große Anzahl der Funktionen (anstatt der Methoden) nur in den globalen Namespace geschrieben werden : Methoden, die sich auf Listen, Zeichenfolgen, Zahlen, Konstruktoren und Metaprogramme beziehen, die alle in einer großen alphabetisch sortierten Liste zusammengefasst sind.

Zumindest haben funktionale Sprachen wie F # alle Funktionen, die ordnungsgemäß in Modulen benannt sind:

List.map(x)
List.reversed(x)
List.any(x)

Sie sind also nicht alle zusammen. Darüber hinaus ist dies ein Standard, der in der gesamten Bibliothek befolgt wird, sodass er zumindest konsistent ist.

Ich verstehe die Gründe für die Funktion vs Methode Sache, aber ich denke immer noch, es ist eine schlechte Idee, sie so zu mischen. Ich wäre viel glücklicher, wenn die Methodensyntax befolgt würde, zumindest für die üblichen Operationen:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Unabhängig davon, ob die Methoden mutieren oder nicht, hat es mehrere Vorteile, sie als Methoden für das Objekt zu haben:

• Einzelner Ort, um die "allgemeinen" Operationen für einen Datentyp nachzuschlagen: andere Bibliotheken / etc. Möglicherweise haben sie andere ausgefallene Dinge, die sie mit den Datentypen tun können, aber die "Standard" -Operationen sind alle in den Methoden des Objekts.
• Sie müssen das nicht mehr wiederholen, Modulewenn Sie anrufen Module.method(x). Warum muss ich im obigen Funktionslisten-Beispiel immer wieder etwas sagen List? Es sollte wissen, dass es ein ist Listund ich möchte die Navigation.map()Funktion nicht darauf aufrufen ! Mit der x.map()Syntax bleibt es trocken und dennoch eindeutig.

Und natürlich hat es Vorteile gegenüber der Art und Weise , wie alles in einem globalen Namespace abgelegt wird . Es ist nicht so, dass der gegenwärtige Weg nicht in der Lage ist , Dinge zu erledigen. Es ist sogar ziemlich knapp ( len(lst)), da nichts mit einem Namensraum versehen ist! Ich verstehe die Vorteile der Verwendung von Funktionen (Standardverhalten usw.) gegenüber Methoden, aber es gefällt mir immer noch nicht.

Es ist nur chaotisch. Und in großen Projekten ist Unordnung Ihr schlimmster Feind.

Mangel an Homoikonizität .

Python musste darauf warten, dass 3.x ein "with" -Stichwort hinzufügte. In jeder homoikonischen Sprache könnte es trivial in eine Bibliothek aufgenommen worden sein.

Die meisten anderen Probleme, die ich in den Antworten gesehen habe, sind einer von drei Arten:

1) Dinge, die mit Werkzeugen repariert werden können (z. B. Pyflakes) 2) Implementierungsdetails (GIL, Leistung) 3) Dinge, die mit Codierungsstandards repariert werden können (dh Features, von denen man wünscht, sie wären nicht da)

# 2 ist kein Problem mit der Sprache, IMO # 1 und # 3 sind keine ernsthaften Probleme.

Python ist meine Lieblingssprache, da es sehr ausdrucksstark ist, aber Sie trotzdem davon abhält, zu viele Fehler zu machen. Ich habe noch ein paar Dinge, die mich nerven:

• Keine echten anonymen Funktionen. Lambda kann für Funktionen mit nur einer withAnweisung verwendet werden , und die Anweisung kann für viele Dinge verwendet werden, bei denen Sie einen Codeblock in Ruby verwenden würden. Aber in manchen Situationen sind die Dinge etwas ungeschickter, als sie sein müssten. (Weit davon entfernt, so ungeschickt wie es in Java sein würde, aber immer noch ...)

• Einige Verwirrung in der Beziehung zwischen Modulen und Dateien. Das Ausführen von "python foo.py" über die Befehlszeile unterscheidet sich von "import foo". Relative Importe in Python 2.x können ebenfalls Probleme verursachen. Dennoch sind Pythons Module viel besser als die entsprechenden Funktionen von C, C ++ und Ruby.

• Explizit self. Obwohl ich einige der Gründe dafür verstehe und Python täglich verwende, mache ich den Fehler, es zu vergessen. Ein weiteres Problem dabei ist, dass es ein bisschen langweilig wird, eine Klasse aus einem Modul zu erstellen. Explizites Selbst hängt mit dem begrenzten Umfang zusammen, über den sich andere beschwert haben. Der kleinste Bereich in Python ist der Funktionsumfang. Wenn Sie Ihre Funktionen klein halten, wie Sie sollten, ist das kein Problem für sich und IMO liefert häufig saubereren Code.

• Einige globale Funktionen, z. B. leneine Methode, von der Sie erwarten würden, dass sie sich hinter den Kulissen befindet.

• Signifikante Einrückung. Nicht die Idee selbst, die ich großartig finde, aber da dies die einzige Sache ist, die so viele Leute davon abhält, Python auszuprobieren, wäre Python vielleicht mit einigen (optionalen) Anfangs- / Endesymbolen besser dran. Wenn ich diese Leute ignoriere, könnte ich auch mit einer erzwungenen Größe für den Einzug leben.

• Dass es nicht die eingebaute Sprache von Webbrowsern ist, sondern JavaScript.

Von diesen Beschwerden ist es nur die allererste, die mir so wichtig ist, dass ich denke, dass sie der Sprache hinzugefügt werden sollten. Die anderen sind eher geringfügig, bis auf die letzte, was großartig wäre, wenn es passieren würde!

Python ist noch nicht ausgereift: Die Sprache Python 3.2 weist derzeit Kompatibilitätsprobleme mit den meisten derzeit verteilten Paketen auf (normalerweise sind sie mit Python 2.5 kompatibel). Dies ist ein großer Nachteil, der derzeit mehr Entwicklungsaufwand erfordert (Finden des benötigten Pakets; Überprüfen der Kompatibilität; Wiegen der Auswahl eines nicht so guten Pakets, das möglicherweise kompatibler ist; Verwenden der besten Version; Aktualisieren auf 3.2, was dann Tage dauern könnte) anfangen, etwas Nützliches zu tun).

Voraussichtlich Mitte 2012 wird dies weniger nachteilig sein.

Beachten Sie, dass ich wohl von einem Fan-Boy abgewertet wurde. Während einer Entwicklerdiskussion kam unser hochrangiges Entwicklerteam jedoch zu dem gleichen Ergebnis.

Reife bedeutet, dass ein Team die Technologie nutzen und ohne versteckte Risiken (einschließlich Kompatibilitätsprobleme) sehr schnell einsatzbereit ist. Python-Pakete von Drittanbietern und viele Apps funktionieren heutzutage bei den meisten Paketen nicht unter 3.2. Dies schafft mehr Arbeit für die Integration, das Testen und die Neuimplementierung der Technologie selbst, anstatt das vorliegende Problem zu lösen == weniger ausgereifte Technologie.

Update für Juni 2013: Python 3 hat immer noch Laufzeitprobleme. Von Zeit zu Zeit erwähnt ein Teammitglied ein erforderliches Paket und sagt dann "außer es ist nur für 2.6" Unsere Werkzeuge bleiben bei 3.2). Nicht einmal MoinMoin, das reine Python-Wiki, ist in Python 3 geschrieben.

Der Umfang von Python ist sehr schlecht, was die objektorientierte Programmierung in Python sehr umständlich macht.

Meine Griffe über Python:

• Angeschraubte OOP (Siehe @ mipadis Antwort zur Erarbeitung dieser Frage)
• Fehlerhafte Implementierung von Lambdas
• Umfangsprobleme
• Keine persistenten Sammlungen in der Standardbibliothek
• Schlechte Eignung für eingebettete DSLs

Zugriffsmodifikatoren in Python können nicht erzwungen werden - dies erschwert das Schreiben von gut strukturiertem, modularisiertem Code.

Ich nehme an, das ist Teil von @ Masons kaputtem Scoping - ein großes Problem im Allgemeinen mit dieser Sprache. Für Code, der lesbar sein soll, scheint es ziemlich schwierig zu sein, herauszufinden, welcher Umfang und welcher Wert zu einem bestimmten Zeitpunkt vorhanden sein kann und sollte - ich denke derzeit aufgrund dieser Nachteile darüber nach, von der Python-Sprache abzuweichen .

Nur weil "wir alle Erwachsenen zustimmen", heißt das nicht, dass wir keine Fehler machen und in einer starken Struktur nicht besser arbeiten, besonders wenn wir an komplexen Projekten arbeiten - Einrückungen und bedeutungslose Unterstriche scheinen nicht ausreichend zu sein .

1. Die leistung ist nicht gut, aber verbessert sich mit pypy,
2. Die GIL verhindert die Verwendung von Threading zur Beschleunigung des Codes (obwohl dies normalerweise eine vorzeitige Optimierung ist).
3. Es ist nur für die Anwendungsprogrammierung nützlich,

Aber es hat einige großartige Einlösungsfunktionen:

1. Es ist perfekt für RAD,
2. Es ist einfach, mit C zu kommunizieren (und für C einen Python-Interpreter einzubetten),
3. Es ist sehr lesbar,
4. Es ist leicht zu lernen,
5. Es ist gut dokumentiert,
6. Batterien sind im Lieferumfang enthalten, die Standardbibliothek ist riesig und pypi enthält Module für praktisch alles,
7. Es hat eine gesunde Gemeinschaft.

Ich bevorzuge Python, und der erste Nachteil, der mir einfällt, ist, dass Sie beim Auskommentieren einer Anweisung wie if myTest():dieser den Einzug des gesamten ausgeführten Blocks ändern müssen, was Sie mit C oder Java nicht tun müssten. Tatsächlich habe ich in Python angefangen, eine if-Klausel zu kommentieren, anstatt sie auszukommentieren: `if True: #myTest (), damit ich nicht auch den folgenden Codeblock ändern muss. Da Java und C nicht auf Einrückungen angewiesen sind, wird das Auskommentieren von Anweisungen mit C und Java erleichtert.

Der Mehrfachversand lässt sich nicht gut in das etablierte Einzelversandsystem integrieren und ist nicht sehr leistungsfähig.

Das dynamische Laden ist ein großes Problem in parallelen Dateisystemen, in denen POSIX-ähnliche Semantiken zu katastrophalen Verlangsamungen für metadatenintensive Vorgänge führen. Ich habe Kollegen, die eine Viertelmillion Kernstunden damit verbracht haben, Python (mit numpy, mpi4py, petsc4py und anderen Erweiterungsmodulen) auf 65k-Kernen zu laden. (Die Simulation lieferte bedeutende neue wissenschaftliche Ergebnisse, es hat sich also gelohnt, aber es ist ein Problem, wenn mehr als ein Barrel Öl verbrannt wird, um Python einmal zu laden.) Die Unfähigkeit, statisch zu verknüpfen, hat uns gezwungen, uns an große Verrenkungen zu gewöhnen angemessene Ladezeiten im Maßstab, einschließlich des Patchens von libc-rtld, um dlopeneinen kollektiven Dateisystemzugriff durchzuführen.

• Eine ganze Reihe von sehr gängigen Bibliotheken und Software von Drittanbietern, die weit verbreitet sind, sind nicht ganz pythonisch. Einige Beispiele: Soaplib, Openerp, Reportlab. Kritik ist unangebracht, da, weit verbreitet, aber sie verwirrt die Python-Kultur (sie verletzt das Motto "Es sollte einen - und am besten nur einen - offensichtlichen Weg geben, dies zu tun"). Bekannte pythonische Erfolge (wie Django oder Trac) scheinen die Ausnahme zu sein.
• Die potenziell unbegrenzte Abstraktionstiefe von Instanz, Klasse und Metaklasse ist konzeptionell wunderschön und einzigartig. Aber um es zu beherrschen, muss man den Interpreter genau kennen (in welcher Reihenfolge der Python-Code interpretiert wird usw.). Es ist nicht weithin bekannt und wird nicht richtig verwendet, während ähnliche schwarze Magie wie C # -Generika, die konzeptionell komplexer ist (IMHO), proportional weithin bekannt und verwendet zu sein scheint.
• Um ein gutes Verständnis für das Gedächtnis und das Threading-Modell zu bekommen, müssen Sie mit Python vertraut sein, da es keine umfassenden Spezifikationen gibt. Sie wissen einfach, was funktioniert, vielleicht, weil Sie die Quellen des Dolmetschers oder erfahrene Macken gelesen und herausgefunden haben, wie man sie behebt. Zum Beispiel gibt es nur starke oder schwache Referenzen, nicht die Soft- und Phantom-Refs von Java. Java hat einen Thread für die Garbage Collection, während es keine formelle Antwort gibt, wann die Garbage Collection in Python stattfindet. Sie können einfach beobachten, dass die Garbage Collection nicht stattfindet, wenn kein Python-Code ausgeführt wird, und schließen daraus, dass dies möglicherweise manchmal passiert, wenn versucht wird, Speicher zuzuweisen. Kann schwierig sein, wenn Sie nicht wissen, warum eine gesperrte Ressource nicht freigegeben wurde (meine Erfahrung dazu war mod_python in freeswitch).

Wie auch immer, Python ist seit 4 Jahren meine Hauptsprache. Fanboys, Elitisten oder Monomanen zu sein, ist kein Teil der Python-Kultur.

• Seltsame OOP:
  • len(s)durch __len__(self)und andere "spezielle Methoden"
  • Extra spezielle Methoden, die von anderen speziellen Methoden ( __add__und __iadd__für +und +=) abgeleitet werden könnten
  • self als erster Methodenparameter
  • Sie können vergessen, den Basisklassenkonstruktor aufzurufen
  • keine Zugriffsmodifikatoren (privat, geschützt ...)
• keine konstanten Definitionen
• Keine Unveränderlichkeit für benutzerdefinierte Typen
• Gil
• schlechte Performance, die zu einer Mischung aus Python und C führt und Probleme mit Builds hat (Suche nach C-Bibliotheken, Plattformabhängigkeiten ...)
• schlechte Dokumentation, insbesondere in Drittanbieter-Bibliotheken
• Inkompatibilität zwischen Python 2.x und 3.x.
• schlechte Code-Analyse-Tools (im Vergleich zu dem, was für statisch typisierte Sprachen wie Java oder C # angeboten wird)

"Unveränderlichkeit" ist nicht gerade die Stärke. AFAIK-Zahlen, Tupel und Strings sind unveränderlich, alles andere (dh Objekte) ist veränderlich. Vergleichen Sie das mit funktionalen Sprachen wie Erlang oder Haskell, in denen alles unveränderlich ist (zumindest standardmäßig).

Unveränderlichkeit strahlt jedoch wirklich wirklich mit Parallelität * aus, was auch nicht Pythons Stärke ist, also zumindest konsequent.

(* = Für die Nitpicker: Ich meine Parallelität, die zumindest teilweise parallel ist. Ich denke, Python ist in Ordnung mit "single-threaded" Parallelität, in der Unveränderlichkeit nicht so wichtig ist. (Ja, FP-Liebhaber, ich weiß, dass Unveränderlichkeit ist toll auch ohne nebenläufigkeit.))

Ich hätte gerne explizit parallele Konstrukte. Meistens, wenn ich eine Liste wie Verständnis schreibe

[ f(x) for x in lots_of_sx ]

Es ist mir egal, in welcher Reihenfolge die Elemente verarbeitet werden. Manchmal ist es mir sogar egal, in welcher Reihenfolge sie zurückgegeben werden.

Auch wenn CPython es nicht gut kann, wenn mein f reines Python ist, könnte ein solches Verhalten für andere Implementierungen definiert werden.

Python hat keine Tail-Call-Optimierung, hauptsächlich aus philosophischen Gründen . Dies bedeutet, dass die Schwanzrekursion bei großen Strukturen O (n) Speicher kosten kann (aufgrund des unnötigen Stapels, der beibehalten wird), und Sie müssen die Rekursion als Schleife neu schreiben, um O (1) Speicher zu erhalten.