通常，要遵循语言标准库中使用的约定。

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

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

我个人在用其他编程语言开发时使用Java的命名约定，因为它是一致的，易于遵循。这样我就不会一直纠结于使用什么约定，而这本来不应该是我项目中最难的部分!

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

David Goodger(在这里的“像Pythonista一样编码”中)描述了PEP 8的建议如下:

Joined_lower函数，方法， 属性、变量 joined_lower或ALL_CAPS for 常量 课程用的studlycap 骆驼案只符合 已有的约定

@JohnTESlade的回答更进一步。谷歌的python风格指南有一些非常简洁的建议，

避免使用的名字

除计数器或迭代器外的单字符名称 在任何包/模块名称中使用破折号(-) \ __double_leading_and_trailing_下划线名称(由Python保留)

命名约定

"Internal" means internal to a module or protected or private within a class. Prepending a single underscore (_) has some support for protecting module variables and functions (not included with import * from). Prepending a double underscore (__) to an instance variable or method effectively serves to make the variable or method private to its class (using name mangling). Place related classes and top-level functions together in a module. Unlike Java, there is no need to limit yourself to one class per module. Use CapWords for class names, but lower_with_under.py for module names. Although there are many existing modules named CapWords.py, this is now discouraged because it's confusing when the module happens to be named after a class. ("wait -- did I write import StringIO or from StringIO import StringIO?")

指南源自圭多的建议