it-swarm.dev

Was sind die Nachteile von Python?

Python scheint heutzutage der letzte Schrei zu sein, und das nicht unverdient - denn es ist wirklich eine Sprache, mit der man fast gerne ein neues Problem zu lösen bekommt. Aber wie ein weiser Mann einmal sagte (ihn einen weiser Mann nannte, nur weil ich keine Ahnung habe, wer es tatsächlich gesagt hat; nicht sicher, ob er so weise war all), um eine Sprache wirklich zu kennen, kennt man nicht nur ihre Syntax, ihr Design usw., sondern auch ihre 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 ein Ziel (bis zu einem gewissen Grad) Meinung, welche Sprachfunktionen schlecht gestaltet sind, ob, welche fehlen Ihnen möglicherweise und so weiter. Wenn Sie eine andere Sprache als Vergleich verwenden müssen, aber nur, um einen Punkt zu veranschaulichen, der sonst schwer zu erläutern wäre (z. B. z Leichtigkeit des Verständnisses)

147
Rook

Ich benutze Python etwas regelmäßig, und insgesamt halte ich es 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. Oft spielt dies keine Rolle, aber es bedeutet definitiv, dass Sie eine andere Sprache für diese leistungskritischen Elemente benötigen.

  2. Verschachtelte Funktionen saugen ein, dass Sie Variablen im äußeren Bereich nicht ändern können. Bearbeiten: Ich verwende immer noch Python 2 aufgrund der Bibliotheksunterstützung, und dieser Designfehler irritiert mich zum Teufel). aber anscheinend ist es in Python 3 aufgrund der Anweisung nonlocal behoben. Ich kann es kaum erwarten, dass die von mir verwendeten Bibliotheken portiert werden, damit dieser Fehler an die Asche gesendet werden kann Haufen Geschichte für immer.

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

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

  5. Ich habe zwar nichts dagegen, dass es nicht möglich ist, semantische Fehler im Voraus als Kompromiss für die Dynamik zu erfassen, die Python Ich wünschte, es gäbe eine Möglichkeit, syntaktische Fehler und alberne Dinge wie das falsche Eingeben von Variablennamen zu erkennen, ohne den Code tatsächlich ausführen zu müssen.

  6. Die Dokumentation ist nicht so gut wie Sprachen wie PHP und Java) mit starker Unternehmensunterstützung.

109
dsimcha

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

Außerdem verwende ich normalerweise Python -Variablen in einem einmaligen Schreibstil, dh ich behandle Variablen als unveränderlich und ändere sie nicht nach ihrer ersten Zuweisung. Dank Funktionen wie Listenverständnis Dies ist tatsächlich unglaublich einfach und erleichtert das Verfolgen des Codeflusses.

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: var und let. Wenn ich in eine Variable schreibe, die von keiner dieser Variablen deklariert wurde, sollte Python sollte einen Fehler auslösen. Außerdem deklariert let Variablen als schreibgeschützt, während var Variablen sind "normal".

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 (aber let -Variablen sind in jeder Hinsicht statisch typisiert, da sie nicht auf einen neuen Wert zurückgesetzt werden können, während var -Variablen möglicherweise noch dynamisch typisiert werden).

Schließlich sollten alle Methodenargumente automatisch let sein, d. H. Sie sollten schreibgeschützt sein. Es gibt im Allgemeinen keinen guten Grund, einen Parameter zu ändern, außer 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]
66
Konrad Rudolph

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

Es gibt jedoch eine Multiprozess-Schnittstelle , die sehr einfach zu verwenden ist, jedoch die Speicherauslastung für die gleiche Anzahl von Prozessen im Vergleich zu Threads erhöht oder schwierig ist, wenn Sie viele gemeinsam genutzte Daten haben . Der Vorteil ist jedoch, dass ein Programm, an dem mit mehreren Prozessen gearbeitet wird, auf mehrere Computer skaliert werden kann, was ein Thread-Programm nicht kann.

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 laufenden Laufzeitfehler abfangen, die pylint ausführen.

44
cmcginty

Wohl, das Fehlen einer statischen Typisierung, die bestimmte Klassen von Laufzeit Fehlern einführen kann, ist die zusätzliche Flexibilität, die die Ententypisierung bietet, nicht wert.

28
Jacob

Ich denke, die objektorientierten Teile von Python fühlen sich irgendwie "angeschraubt" an. Die ganze Notwendigkeit, "self" explizit an jede Methode zu übergeben, ist ein Symptom dafür, dass die Komponente OOP nicht ausdrücklich geplant war , könnte man sagen; Es zeigt auch Pythons manchmal warme Scoping-Regeln, die in einer anderen Antwort kritisiert wurden.

Edit :

Wenn ich sage, dass sich Pythons objektorientierte Teile "angeschraubt" anfühlen, meine ich, dass sich die OOP Seite manchmal ziemlich inkonsistent anfühlt. Nehmen wir zum Beispiel Ruby: In Ruby ist alles ein Objekt, und Sie rufen eine Methode mit der bekannten Syntax obj.method Auf (mit Ausnahme überladener Operatoren von) Kurs); In Python ist auch alles ein Objekt, aber einige Methoden rufen Sie als Funktion auf. Sie überladen __len__, um eine Länge zurückzugeben, rufen sie jedoch mit len(obj) auf, anstatt mit dem in anderen Sprachen üblichen (und konsistenteren) obj.length. Ich weiß, dass es Gründe für diese Designentscheidung gibt, aber ich mag sie nicht.

Außerdem fehlt Pythons OOP -Modell jeglicher Datenschutz, d. H. Es gibt keine privaten, geschützten und öffentlichen Mitglieder. Sie können sie mit _ und __ vor Methoden nachahmen, aber es ist irgendwie hässlich. In ähnlicher Weise versteht Python den Aspekt der Nachrichtenübermittlung von OOP auch nicht ganz richtig.

27
mipadi

Dinge, die ich an Python nicht mag:

  1. Threading (ich weiß, dass es bereits erwähnt wurde, aber in jedem Beitrag erwähnenswert).
  2. Keine Unterstützung für mehrzeilige anonyme Funktionen (lambda kann nur einen Ausdruck enthalten).
  3. Fehlen einer einfachen, aber leistungsstarken Eingabe-Lesefunktion/-klasse (wie cin oder scanf in C++ und C oder Scanner in Java).
  4. Alle Zeichenfolgen sind standardmäßig nicht Unicode (sondern in Python 3) festgelegt.
19
MAK

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, wenn ein neues Listenobjekt erstellt würde, 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 etwas in den Dokumenten erwähnt werden muss, bedeutet dies normalerweise, dass es ein Problem ist. Dies sollte nicht erforderlich sein.

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

Besonders wenn das die Standardeinstellung gewesen sein sollte. Es ist nur ein seltsames Verhalten, das nicht Ihren Erwartungen entspricht und für eine Vielzahl von Umständen nicht nützlich ist.

18
jsternberg

Einige der Funktionen von Python, die es als Entwicklungssprache so flexibel machen, werden auch von denjenigen als Hauptnachteile angesehen, die für die statische Analyse des gesamten Programms verwendet werden, die durch den Kompilierungs- und Verknüpfungsprozess 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 erfasst werden muss (globale und nicht lokale Deklarationen für äußere Bereiche, Attributzugriffsnotation für beispielsweise Bereiche). Dies reduziert massiv die Menge an Boilerplate, die beim Programmieren benötigt wird, bedeutet jedoch, dass statische Analysetools von Drittanbietern (z. B. Pyflakes) erforderlich sind, um Überprü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 der eingebaute Namespace 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 bietet einige Funktionen, die statisch typisierten OO Sprachen) gemeinsam sind. Insbesondere ist der Parameter "self" für Instanzmethoden explizit anstatt implizit (da "Methoden" nicht innerhalb einer Klasse definiert werden müssen, können sie später durch Ändern der Klasse hinzugefügt werden, was bedeutet, dass es nicht besonders praktisch ist, die Instanzreferenz implizit zu übergeben) und Attributzugriffskontrollen können ' Es kann leicht erzwungen werden, basierend darauf, ob sich der Code "innerhalb" oder "außerhalb" der Klasse befindet oder nicht (da diese Unterscheidung nur besteht, während die Klassendefinition ausgeführt wird).

  • Weit weg vom Metall

Dies gilt auch für viele andere Hochsprachen, aber Python neigt dazu, die meisten Hardwaredetails zu abstrahieren. Systemprogrammiersprachen wie C und C++ sind immer noch weitaus besser für den direkten Hardwarezugriff geeignet (jedoch) Python spricht sehr gerne mit diesen entweder über CPython-Erweiterungsmodule oder portabler über die Bibliothek ctypes).

14
ncoghlan
  1. Verwenden von Einrückungen für Codeblöcke anstelle von {}/begin-end, was auch immer.
  2. Jede neuere moderne Sprache hat einen angemessenen lexikalischen Geltungsbereich, jedoch nicht Python (siehe unten)).
  3. Chaotische Dokumente (vergleiche mit der Perl5-Dokumentation, die hervorragend ist).
  4. Zwangsjacke (es gibt nur einen Weg, dies zu tun).

Beispiel für gebrochenes Scoping; Transkript von 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

global und nonlocal Schlüsselwörter wurden eingeführt, um diese Design-Dummheit zu patchen.

12
zvrba

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 (anstelle von Methoden) nur in den globaler Namespace : Methoden für Listen, Zeichenfolgen, Zahlen, Konstruktoren und Metaprogrammierung geschrieben werden, die alle in einem großen zusammengefasst sind alphabetisch sortierte Liste.

Zumindest haben funktionale Sprachen wie F # alle Funktionen, die in Modulen richtig 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 Ausführung der Funktion vs Methode , aber ich Ich denke immer noch, dass es eine schlechte Idee ist, sie so zu verwechseln. Ich wäre viel glücklicher, wenn die Methodensyntax befolgt würde, zumindest für die allgemeinen 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:

  • Ein einziger 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 enthalten.
  • Sie müssen Module beim Aufrufen von Module.method(x) nicht ständig wiederholen. Warum muss ich im obigen Beispiel der Funktionsliste immer wieder List sagen? Es sollte wissen, dass es ein List ist und ich möchte nicht die Navigation.map() Funktion darauf aufrufen! Wenn Sie die Syntax x.map() verwenden, bleibt diese DRY und immer noch eindeutig).

Und natürlich hat es Vorteile gegenüber der Methode, alles in den globalen Namespace zu setzen . Es ist nicht so, dass der derzeitige Weg nicht in der Lage ist , Dinge zu erledigen. Es ist sogar ziemlich knapp (len(lst)), da nichts mit Namespaces versehen ist! Ich verstehe die Vorteile der Verwendung von Funktionen (Standardverhalten usw.) gegenüber Methoden, aber ich mag es immer noch nicht.

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

11
Haoyi

Mangel an Homoikonizität .

Python musste auf 3.x warten, um ein "with" -Schlüsselwort hinzuzufügen. In jeder homoikonischen Sprache hätte es trivial in eine Bibliothek aufgenommen werden können.

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

1) Dinge, die mit Werkzeugen behoben werden können (z. B. Pyflakes) 2) Implementierungsdetails (GIL, Leistung) 3) Dinge, die mit Codierungsstandards behoben werden können (d. H. Funktionen, von denen die Leute wünschten, sie wären nicht da)

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

8
Jason

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 einer Anweisung verwendet werden, und die Anweisung with kann für viele Dinge verwendet werden, bei denen Sie in Ruby einen Codeblock verwenden würden. Aber in manchen Situationen macht es die Dinge etwas ungeschickter, als sie sein müssten. (Weit davon entfernt, so ungeschickt wie in Java zu sein, 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 so viel besser als die entsprechenden Funktionen von C, C++ und Ruby.

  • Explizites self. Obwohl ich einige der Gründe dafür verstehe und Python täglich) verwende, neige ich dazu, den Fehler zu machen, es zu vergessen. Ein weiteres Problem dabei ist, dass es etwas langweilig wird Machen Sie eine Klasse aus einem Modul. 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 so klein halten, wie Sie sollte, das ist kein Problem für sich und IMO gibt oft saubereren Code.

  • Einige globale Funktionen, wie z. B. len, von denen Sie erwarten würden, dass sie eine Methode sind (die sich tatsächlich 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 vielleicht Python mit einigen (optionalen) Anfang/Ende besser dran Wenn ich diese Leute ignoriere, könnte ich auch mit einer erzwungenen Größe für die Einrückung leben.

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

Von diesen Beschwerden ist es nur die allererste, die mir wichtig genug ist, und ich denke, sie sollte der Sprache hinzugefügt werden. Die anderen sind eher klein, bis auf den letzten, was großartig wäre, wenn es passieren würde!

7
Martin Vilcans

Python ist noch nicht vollständig ausgereift: Die Sprache python 3.2 weist derzeit Kompatibilitätsprobleme mit den meisten derzeit verteilten Paketen auf (normalerweise sind sie mit python) kompatibel 2.5) Dies ist ein großer Nachteil, der derzeit mehr Entwicklungsaufwand erfordert (Finden Sie das benötigte Paket; Überprüfen Sie die Kompatibilität; Wiegen Sie die Auswahl eines nicht so guten Pakets, das möglicherweise kompatibler ist; nehmen Sie die beste Version und aktualisieren Sie es auf 3.2, was möglicherweise erforderlich ist Tage; dann fange an, etwas Nützliches zu tun).

Voraussichtlich Mitte 2012 wird dies weniger nachteilig sein.

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

Reife in einem Hauptsinn bedeutet, dass ein Team die Technologie nutzen und ohne versteckte Risiken (einschließlich Kompatibilitätsprobleme) sehr schnell einsatzbereit sein kann. Drittanbieter python -Pakete und viele Apps nicht Arbeiten Sie heute für die meisten Pakete unter 3.2. Dies führt zu mehr Integrations-, Test- und Neuimplementierungsarbeit, anstatt das vorliegende Problem zu lösen == weniger ausgereifte Technologie.

Update für Juni 2013: Python 3 hat immer noch Reifeprobleme. Von Zeit zu Zeit erwähnt ein Teammitglied ein benötigtes Paket und sagt dann "außer es ist nur für 2.6" (in einigen dieser Fälle habe ich ' Wir haben eine Problemumgehung über den localhost-Socket implementiert, um das Nur-2.6-Paket mit 2.6 zu verwenden, und der Rest unserer Tools bleibt bei 3.2. Nicht einmal MoinMoin, das reine Python-Wiki, ist in Python) geschrieben = 3.

5

Das Scoping von Python ist stark beeinträchtigt, was die objektorientierte Programmierung in Python sehr umständlich) macht.

4
Mason Wheeler

Zugriffsmodifikatoren in Python sind nicht erzwingbar - erschweren 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, was im Umfang sein kann und sollte und welcher Wert zu einem bestimmten Zeitpunkt sein wird - ich denke derzeit darüber nach, von Python Sprache wegen dieser Nachteile.

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

4
Vector

Meine Griffe über Python:

  • Angeschraubt OOP (Siehe @ mipadis Antwort für eine Ausarbeitung dazu)
  • Defekte Implementierung von Lambdas
  • Umfangsprobleme
  • Keine persistenten Sammlungen in der Standardbibliothek
  • Schlechte Eignung für eingebettete DSLs
4
missingfaktor

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

Das dynamische Laden ist ein massives Problem in parallelen Dateisystemen, in denen POSIX-ähnliche Semantik zu katastrophalen Verlangsamungen für metadatenintensive Vorgänge führt. Ich habe Kollegen, die eine Viertelmillion Kernstunden verbrannt haben und gerade Python (mit Numpy, MPI4PY, PetsC4PY und anderen Erweiterungsmodulen)) auf 65.000 Kerne geladen haben. (Die Simulation lieferte eine bedeutende neue Wissenschaft Ergebnisse, also hat es sich gelohnt, aber es ist ein Problem, wenn mehr als ein Barrel Öl zum Laden verbrannt wird Python einmal.) Die Unfähigkeit, statisch zu verknüpfen, hat uns gezwungen, zu großen Verrenkungen zu gehen Erhalten Sie angemessene Ladezeiten im Maßstab, einschließlich des Patchens von libc-rtld, damit dlopen kollektiven Dateisystemzugriff ausführt.

3
Jed
  • eine ganze Reihe von gängigen Bibliotheken und Software von Drittanbietern, die weit verbreitet sind, sind nicht pythonisch. Einige Beispiele: soaplib, openerp, reportlab. Kritik ist außerhalb des Rahmens, sie ist da, sie ist weit verbreitet, aber sie macht die python -Kultur verwirrend (es schadet dem Motto, dass es einen - und vorzugsweise nur einen - offensichtlichen Weg geben sollte es 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 schön und einzigartig. Aber um es zu beherrschen, muss man den Interpreter genau kennen (in welcher Reihenfolge python Code interpretiert wird usw.). Es ist nicht allgemein bekannt und wird verwendet (oder richtig verwendet), während ähnliche schwarze Magie wie C # -Generika, die konzeptionell komplizierter ist (IMHO), proportional bekannter und verwendet zu sein scheint.
  • um einen guten Überblick über das Speicher- und Threading-Modell zu erhalten, müssen Sie mit Python vertraut sein, da es keine umfassende Spezifikation gibt. Sie wissen nur, was funktioniert, vielleicht weil Sie die Quellen des Dolmetschers oder erfahrene Macken gelesen und herausgefunden haben, wie Sie sie beheben können. Zum Beispiel gibt es nur starke oder schwache Referenzen, nicht die Soft- und Phantom-Refs von Java. Java hat einen Thread für die Speicherbereinigung, während es keine formelle Antwort darauf gibt, wann die Speicherbereinigung in python erfolgt. Sie können nur beobachten, dass die Garbage Collection nicht stattfindet, wenn kein python Code ausgeführt wird, und schließen, dass dies wahrscheinlich 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).

Jedenfalls ist python seit 4 Jahren meine Hauptsprache. Fanboys, Elitisten oder Monomanen zu sein, gehört nicht zur python Kultur.

3
vincent

Ich bevorzuge python und der erste Nachteil, der mir einfällt, ist, wenn Sie eine Anweisung wie if myTest(): auskommentieren, dann müssen Sie den Einzug des gesamten ausgeführten Blocks ändern, den Sie nicht möchten hat nichts mit C oder Java zu tun. Tatsächlich habe ich in python anstatt eine if-Klausel auskommentiert) angefangen, sie folgendermaßen auskommentieren: `if True: #myTest ( ), damit ich nicht auch den folgenden Codeblock ändern muss. Da Java und C nicht auf Einrückungen angewiesen sind, erleichtert das Auskommentieren von Anweisungen mit C und Java.

3
Niklas
  1. Die Leistung ist nicht gut, verbessert sich aber mit Pypy,
  2. Die GIL verhindert die Verwendung von Threading, um den Code zu beschleunigen (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 wirklich enthalten, die Standardbibliothek ist riesig und pypi enthält Module für praktisch alles,
  7. Es hat eine gesunde Gemeinschaft.
3
dan_waterworth
  • Seltsame OOP:
    • len(s) bis __len__(self) und andere "spezielle Methoden"
    • spezielle Methoden, die von anderen speziellen Methoden abgeleitet werden könnten (__add__ und __iadd__ zum + und +=)
    • 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 Leistung, die zu einer Mischung aus Python und C und Problemen mit Builds führt (Suche nach C-Bibliotheken, Plattformabhängigkeiten ...)
  • schlechte Dokumentation, insbesondere in Bibliotheken von Drittanbietern
  • 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)
2
deamon

"Unveränderlichkeit" ist nicht gerade seine Stärke. AFAIK-Zahlen, Tupel und Zeichenfolgen sind unveränderlich, alles andere (d. H. 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 glänzt jedoch wirklich mit Parallelität *, was auch nicht die Stärke von Python ist, also ist es 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, bei der Unveränderlichkeit nicht so wichtig ist. (Ja, FP-Liebhaber, ich weiß, dass Unveränderlichkeit auch ohne Parallelität großartig ist.))

0
Kosta

Ich hätte gerne explizit parallele Konstrukte. Meistens, wenn ich ein Listenverständnis wie schreibe

[ f(x) for x in lots_of_sx ]

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

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

0
rbanffy

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

0
a3nm