// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()
# python example
this_is_my_variable = 'a'
def this_is_my_function():
请参考Python PEP 8: 函数和变量名:
函数名应该使用小写字母，单词之间用下划线分隔以提高可读性。
变量名遵循与函数名相同的约定。
mixedCase仅在已经使用此风格的情况下允许使用（例如threading.py），以保持向后兼容性。
Google Python风格指南提出了以下的命名规范：
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。
在CLASS_CONSTANT_NAME中同样应该采用类似的命名方式。
David Goodger（在“像Pythonista一样编写代码”这里）将PEP 8建议描述如下：
函数、方法、属性、变量使用joined_lower
常量使用joined_lower或ALL_CAPS
类名使用StudlyCaps
仅为符合现有约定而使用camelCase
datetime.datetime）不遵循这个约定呢？ - Prahlad Yeriunittest.TestCase.assertEqual和其他相关函数也没有遵循蛇形命名法。事实上，Python标准库的某些部分是在命名规则尚未确定之前开发的，现在我们只能接受它们了。 - wchargin如上所述，PEP 8建议在变量、方法和函数中使用lower_case_with_underscores。
我更喜欢在变量中使用lower_case_with_underscores，在方法和函数中使用mixedCase，这样可以使代码更加明确和易读。因此遵循Python之禅的"显式优于隐式"和"可读性很重要"。
有PEP 8，正如其他答案所示，但PEP 8仅是标准库的风格指南，在该处仅被视为真理。 PEP 8在其他代码片段中最常见的偏差之一是变量命名，特别是对于方法。 没有单一的主导样式，尽管考虑到使用mixedCase的代码量，如果进行严格普查，则可能会得出一个具有mixedCase的PEP 8版本。 在PEP 8中很少有其他偏差是如此普遍。
__double_leading_and_trailing_underscore__ names（Python保留名称）
大多数Python开发人员偏爱使用下划线，但即使我已经使用Python超过5年，我仍然不喜欢它们。它们对我来说只是看起来很丑，但也许这只是因为我脑海中存有Java的影响。
我更喜欢驼峰式命名法，因为它更符合类的命名方式，SomeClass.doSomething()比SomeClass.do_something()更符合逻辑。如果您在Python全局模块索引中查找，您会发现两种命名方式都存在，这是由于它是一个从各个来源收集的库的集合，随着时间的推移而增长，并不像Sun公司那样由一个公司开发，具有严格的编码规则。我想说的是：使用自己喜欢的命名方式，这只是个人口味问题。
make_xpath_predicate, make_xpath_expr, make_html_header, make_html_footer。 - PithikosSomeClass.doSomething() （静态方法通常很少见），而是调用 an_instance.do_something()。 - Dave个人而言，我尽量使用驼峰命名法来定义类名，混合式命名法来定义方法和函数名。变量通常使用下划线分隔（只要我能记得）。这样一来，我可以一眼看出我所调用的内容，而不是所有东西看起来都一样。
有一篇论文研究了这个问题：http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
简而言之，它指出snake_case比camelCase更易读。因此，现代语言在可能的情况下都应该使用snake_case。