如前所述，PEP 8要求对变量、方法和函数使用lower_case_with_下划线。

我更喜欢使用lower_case_with_下划线的变量和mixedCase的方法和函数，使代码更显式和可读。因此，遵循Python的“显式优于隐式”和“可读性很重要”的禅意。

有一篇关于这方面的论文:http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

它说snake_case比camelCase可读性更好。这就是为什么现代语言在任何可能的地方都使用(或应该使用)蛇。

无论是否在课堂上或在课堂外:

变量和函数小写，如下所示:

name = "John"

def display(name):
    print("John")

如果它们多于一个单词，则用下划线“_”分隔，如下所示:

first_name = "John"

def display_first_name(first_name):
    print(first_name)

并且，如果一个变量是一个常量，它是大写的，如下所示:

FIRST_NAME = "John"

正如Python代码风格指南所承认的那样，

Python的命名约定 图书馆有点乱，所以我们 永远不能完全一致

注意，这只是指Python的标准库。如果他们不能保持一致，那么几乎没有希望为所有Python代码拥有一个普遍遵守的约定，不是吗?

从这一点，以及这里的讨论，我可以推断，如果一个人在过渡到Python时继续使用例如Java或c#的(清晰而完善的)变量和函数命名约定，这并不是一个可怕的罪恶。当然，要记住，最好是遵循代码库/项目/团队的流行风格。正如Python风格指南所指出的，内部一致性是最重要的。

尽管把我当异教徒看待吧。:-)和OP一样，我不是一个“Pythonista”，至少现在还不是。

大多数使用python的人更喜欢下划线，但即使我已经使用python 5年多了，我仍然不喜欢它们。我只是觉得它们很丑，但也许这就是我脑子里的爪哇。

I simply like CamelCase better since it fits better with the way classes are named, It feels more logical to have SomeClass.doSomething() than SomeClass.do_something(). If you look around in the global module index in python, you will find both, which is due to the fact that it's a collection of libraries from various sources that grew overtime and not something that was developed by one company like Sun with strict coding rules. I would say the bottom line is: Use whatever you like better, it's just a question of personal taste.

列宁告诉过……我也是来自Java/ c#世界的。还有SQL。 仔细审视我自己，试图找到第一眼就能理解的复杂结构的例子，比如列表字典中的列表，其中所有东西都是对象。 对我来说，骆驼语或它们的变体应该成为任何语言的标准。在复杂句中应保留下划线。