Ich habe festgestellt, dass heutzutage viele Bibliotheken die Verwendung von Strings gegenüber Variablen des Enum-Typs für Parameter bevorzugen.
Wo Leute früher Enums verwenden würden, z.B. dateutil.rulle.FR für einen Freitag scheint sich dies in Richtung String verschoben zu haben (z. B. 'FRI ).
Dasselbe gilt für numpy (oder Pandas), wobei searchsorted zum Beispiel für Strings benutzt wird (zB side = 'left' oder side = ' richtig ') anstatt einer definierten enum. Um Zweifel zu vermeiden, hätte dies vor Python 3.4 leicht als Enum als solches implementiert werden können:
%Vor%Und die Vorteile von enums-type-Variablen sind klar: Sie können sie nicht falsch schreiben, ohne einen Fehler zu erzeugen, sie bieten eine angemessene Unterstützung für IDEs usw.
Warum also Strings überhaupt verwenden, statt Enumerationstypen beizubehalten? Macht dies die Programme nicht viel anfälliger für Benutzerfehler? Es ist nicht so, dass Enums einen Overhead erzeugen - wenn überhaupt sollten sie etwas effizienter sein. Wann und warum ist dieser Paradigmenwechsel passiert?
IMHO ist es eine Frage des Geschmacks. Manche Leute mögen diesen Stil:
%Vor% Ja, wenn Sie searchsorted mit side='foo' aufrufen, erhalten Sie möglicherweise später zur Laufzeit eine AssertionError -Weise - aber der Fehler wird zumindest leicht zu erkennen sein.
Während andere Leute bevorzugen (für die Vorteile, die Sie hervorgehoben haben):
%Vor%Ich favorisiere das erste, weil ich denke, dass selten benutzte Konstanten den Namensraum nicht wert sind. Sie können anderer Meinung sein, und die Leute können sich aufgrund anderer Bedenken auf beide Seiten ausrichten.
Wenn Sie wirklich interessiert sind, hindert Sie nichts daran, Ihre eigenen "enums" zu definieren:
%Vor%Ich denke, es ist nicht wert, aber wieder ist es eine Frage des Geschmacks.
[Update]
Stefan hat einen schönen Punkt gemacht:
Sobald sich die Notwendigkeit ergibt, den Wert eines solchen Enums zu ändern, ist es nicht meine Vorstellung von Spaß, an vielen Stellen nachzusehen und eine Saite zu ersetzen: -)
Ich kann sehen, wie schmerzhaft das in einer Sprache ohne benannte Parameter sein kann - mit dem Beispiel musst du nach der Zeichenkette 'right' suchen und viele falsche Positive erhalten. In Python können Sie die Suche auf side='right' beschränken.
Wenn Sie es mit einer Schnittstelle zu tun haben, die bereits eine definierte Menge von enums / Konstanten hat (wie eine externe C-Bibliothek), dann sollten Sie die bestehenden Konventionen auf jeden Fall nachahmen.
Ich denke, Enums sind sicherer, vor allem für größere Systeme mit mehreren Entwicklern.
Sobald sich die Notwendigkeit ergibt, den Wert eines solchen Enums zu ändern, ist es nicht meine Vorstellung von Spaß, an vielen Stellen nachzusehen und eine Saite zu ersetzen: -)
Die wichtigsten Kriterien IMHO ist die Verwendung: Für die Verwendung in einem Modul oder sogar einem Paket scheint eine Zeichenfolge in Ordnung zu sein, in einer öffentlichen API würde ich enums bevorzugen.
Genau genommen hat Python keine enums - oder zumindest nicht vor v3.4
Ich bevorzuge es, Ihr Beispiel als vom Programmierer definierte Konstanten zu betrachten.
In argparse hat eine Gruppe von Konstanten String-Werte. Während der Code die Konstantennamen verwendet, verwenden Benutzer häufiger die Strings.
numpy ist eines der älteren Pakete von Drittanbietern (zumindest seine Wurzeln wie numeric sind). String-Werte sind häufiger als Enums. In der Tat kann ich nicht von irgendwelchen enums (wie Sie sie definieren) denken.
Tags und Links python coding-style numpy