Was ist die Namenskonvention in Python für Variable und Funktion?

Question 1

Aus einem C#-Hintergrund stammend, sind die Namenskonventionen für Variablen und Methodennamen normalerweise entweder camelCase oder PascalCase:

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

In Python habe ich das Obige gesehen, aber ich habe auch gesehen, dass Unterstriche verwendet wurden:

# python example
this_is_my_variable="a"
def this_is_my_function():

Gibt es einen vorzuziehenden, endgültigen Codierungsstil für Python?

Question 2

Siehe Python PEP 8: Funktions- und Variablennamen:

Funktionsnamen sollten sein Kleinbuchstaben, wobei Wörter durch Unterstriche getrennt sind wie nötig, um die Lesbarkeit zu verbessern.

Variablennamen folgen der gleichen Konvention wie Funktionsnamen.

gemischter Fall ist nur in Kontexten erlaubt, in denen dies bereits der vorherrschende Stil ist (z threading.py), um die Abwärtskompatibilität zu erhalten.

Question 3

Das Google Python-Styleguide hat folgende Konvention:

module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name.

Ein ähnliches Namensschema sollte auf a angewendet werden CLASS_CONSTANT_NAME

Question 4

David Goodger (in „Code wie ein Pythonista“ hier) beschreibt die PEP 8-Empfehlungen wie folgt:

joined_lower für Funktionen, Methoden, Attribute, Variablen
joined_lower oder ALL_CAPS für Konstanten
StudlyCaps für Klassen

camelCase nur um bestehenden Konventionen zu entsprechen

Question 5

Als die Styleguide für Python-Code gibt zu,

Die Namenskonventionen der Python-Bibliothek sind ein bisschen chaotisch, also werden wir das nie ganz konsistent bekommen

Beachten Sie, dass sich dies nur auf Pythons bezieht Standardbibliothek. Wenn sie nicht kommen können das konsistent, dann besteht kaum Hoffnung auf eine allgemeingültige Konvention für alle Python-Code, gibt es?

Daraus und aus der Diskussion hier würde ich schließen, dass es so ist nicht eine schreckliche Sünde, wenn man beim Übergang zu Python weiterhin die (eindeutigen und etablierten) Namenskonventionen von Java oder C# für Variablen und Funktionen verwendet. Denken Sie natürlich daran, dass es am besten ist, sich an den vorherrschenden Stil für eine Codebasis / ein Projekt / ein Team zu halten. Wie der Python Style Guide betont, innere Konsistenz zählt am meisten.

^{Fühlen Sie sich frei, mich als Ketzer abzutun. 🙂 Wie das OP bin ich kein “Pythonista”, jedenfalls noch nicht.}

Question 6

Wie bereits erwähnt, sagt PEP 8 zu verwenden lower_case_with_underscores für Variablen, Methoden und Funktionen.

Ich benutze lieber lower_case_with_underscores für Variablen u mixedCase für Methoden und Funktionen macht den Code expliziter und lesbarer. So nach dem Zen von Pythons „explizit ist besser als implizit“ und „Lesbarkeit zählt“

Question 7

Es gibt PEP 8, wie andere Antworten zeigen, aber PEP 8 ist nur der Styleguide für die Standardbibliothek und wird darin nur als Evangelium angesehen. Eine der häufigsten Abweichungen von PEP 8 für andere Codeteile ist die Variablenbenennung, speziell für Methoden. Es gibt keinen einzigen vorherrschenden Stil, obwohl man in Anbetracht der Menge an Code, der mixedCase verwendet, bei einer strengen Zählung wahrscheinlich mit einer Version von PEP 8 mit mixedCase enden würde. Es gibt kaum eine andere Abweichung von PEP 8, die so häufig vorkommt.

Question 8

weiter zu dem, was @JohnTESlade geantwortet hat. Python-Styleguide von Google hat einige ziemlich nette Empfehlungen,

Zu vermeidende Namen

Einzelzeichennamen mit Ausnahme von Zählern oder Iteratoren

Bindestriche (-) in jedem Paket-/Modulnamen
\__double_leading_and_trailing_underscore__ names (reserviert von Python)

Namenskonvention

“Intern” bedeutet intern für ein Modul oder geschützt oder privat innerhalb einer Klasse.
Das Voranstellen eines einzelnen Unterstrichs (_) bietet eine gewisse Unterstützung für den Schutz von Modulvariablen und -funktionen (nicht in import * from enthalten). Das Voranstellen eines doppelten Unterstrichs (__) an eine Instanzvariable oder -methode dient effektiv dazu, die Variable oder Methode für ihre Klasse privat zu machen (unter Verwendung von Namensverfälschung).
Platzieren Sie zusammengehörige Klassen und Top-Level-Funktionen in einem Modul. Anders als bei Java müssen Sie sich nicht auf eine Klasse pro Modul beschränken.

Verwenden CapWords für Klassennamen, aber lower_with_under.py für Modulnamen. Obwohl es viele vorhandene Module gibt, die benannt werden CapWords.py, davon wird jetzt abgeraten, da es verwirrend ist, wenn das Modul zufällig nach einer Klasse benannt wird. (“Warte – habe ich geschrieben import StringIO oder from StringIO import StringIO?”)

Leitlinien abgeleitet von Guidos Empfehlungen