Quelle est la convention de nommage en Python pour les noms de variables et de fonctions?

Google Python Style Guide a la convention suivante:

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

un schéma d'appellation similaire devrait être appliqué à un CLASS_CONSTANT_NAME

David Goodger (in "Code Like a Pythonista" here ) décrit les recommandations du PEP 8 comme suit:

• joined_lower pour les fonctions, les méthodes, attributs, variables

• joined_lower ou ALL_CAPS pour constantes

• StudlyCaps pour les classes

• camelCase seulement pour se conformer à conventions préexistantes

comme le Guide de Style pour le Code Python admet,

les conventions de nommage de Python bibliothèque sont un peu de désordre, de sorte que nous allons ne jamais obtenir ce complètement cohérent

notez que cela se réfère uniquement à la bibliothèque standard de Python . S'ils ne peuvent pas obtenir que conforme, alors il ya à peine beaucoup d'espoir d'avoir un Généralement-adhéré-à convention pour tous code Python, n'est-ce pas?

à partir de là, et de la discussion ici, je déduirais que c'est et non un horrible péché si on continue à utiliser par exemple les conventions de nommage Java ou C#(claires et bien établies) pour les variables et les fonctions lors du passage à Python. En gardant à l'esprit, bien sûr, qu'il est préférable de respecter quel que soit le style dominant pour un codebase / projet / équipe se trouve être. Comme le Python Guide de Style souligne, cohérence interne les questions les plus importantes.

^{n'hésitez pas à me rejeter comme hérétique. :-) Comme l'OP, je ne suis pas un "Pythonista", pas encore en tout cas.}

il y a PEP 8 , comme le montrent d'autres réponses, mais PEP 8 est seulement le styleguide pour la bibliothèque standard, et il est seulement pris comme l'Évangile là-bas. Une des déviations les plus fréquentes de PEP 8 pour les autres morceaux de code est la variable naming, spécifiquement pour les méthodes. Il n'y a pas de style unique dominant, bien que considérant le volume de code qui utilise mixedCase, si on devait faire un recensement strict on finirait probablement avec une version de PEP 8 avec mixedCase. Il y a peu d'autres déviations par rapport à PEP 8 qui sont tout aussi fréquentes.

comme mentionné, PEP 8 dit d'utiliser lower_case_with_underscores pour les variables, les méthodes et les fonctions.

je préfère utiliser lower_case_with_underscores pour les variables et mixedCase pour les méthodes et les fonctions rend le code plus explicite et lisible. Ainsi, suivant le Zen de Python "explicite vaut mieux qu'implicite" et" la lisibilité compte "

personnellement, j'essaie D'utiliser CamelCase pour les classes, les méthodes mixedCase et les fonctions. Les Variables sont habituellement séparées par des underscores (quand je peux me souvenir). De cette façon, je peux dire en un coup d'oeil ce que j'appelle exactement, plutôt que tout semble le même.

la plupart des gens de python préfèrent les underscores, mais même si j'utilise python depuis plus de 5 ans maintenant, je ne les aime toujours pas. Ils sont moches pour moi, mais c'est peut-être tout ce que j'ai dans la tête.

j'aime tout simplement CamelCase mieux car il correspond mieux à la façon dont les classes sont nommées, il se sent plus logique d'avoir SomeClass.doSomething() que SomeClass.do_something() . Si vous regardez autour de vous dans l'index du module global en python, vous trouverez les deux, ce qui est dû au fait que c'est une collection de bibliothèques de diverses sources qui a grandi heures supplémentaires et pas quelque chose qui a été développé par une société comme Sun avec des règles de codage strictes. Je dirais que l'essentiel est: Utilisez ce que vous voulez mieux, c'est juste une question de goût personnel.

il y a un papier à ce sujet: http://www.cs.kent.edu/~jmaletic / papers / ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR il dit que snake_case est plus lisible que camelCase. C'est pourquoi les langues modernes utilisent (ou devraient utiliser) le serpent partout où elles le peuvent.

suite à ce que @JohnTESlade a répondu. Guide de style Python de Google a quelques recommandations assez soignées,

noms à éviter

• noms à caractère unique, sauf pour les compteurs ou les itérateurs
• tirets ( - ) dans n'importe quel nom de paquet/module
• \__double_leading_and_trailing_underscore__ names (réservé par Python)

Convention De Nommage

• "interne" interne à un module ou protégé ou privé à l'intérieur d'une classe.
• préparer un simple caractère de soulignement ( _ ) a un certain support pour protéger les variables et les fonctions du module (non inclus avec import * from). Préparer un double underscore ( _ _ _ ) à une variable d'instance ou une méthode sert effectivement à rendre la variable ou la méthode privée de sa classe (en utilisant le nom mangling).
• placez les classes apparentées et les fonctions de haut niveau ensemble dans un module. Contrairement à Java, il n'est pas nécessaire de se limiter à une classe par module.
• utilisez CapWords pour les noms de classe, mais lower_with_under.py pour les noms de modules. Bien qu'il y ait beaucoup de modules existants nommés CapWords.py , cela est maintenant découragé parce que c'est déroutant quand le module se trouve être nommé d'après une classe. ("attends, est-ce que j'écris import StringIO ou from StringIO import StringIO ?")

lignes Directrices dérivé de Guido Recommandations du

le style de codage fait habituellement partie des normes internes des politiques/conventions d'une organisation, mais je pense qu'en général, le style all_lower_case_underscore_separator (aussi appelé snake_case) est le plus commun en python.

typiquement, on suit les conventions utilisées dans la bibliothèque standard de la langue.