来自Cbackground的变量和方法名称的命名约定通常为CamelCase或者Pascal Case：

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

在Python中，我已经看到了上述内容，但也看到了使用下划线的情况：

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

有没有更优选的，确定的Python编码风格？

解决方案

参见Python PEP 8.

Function names should be lowercase,
  with words separated by underscores as
  necessary to improve readability.
  
  mixedCase is allowed only in contexts
  where that's already the prevailing
  style

变数...

Use the function naming rules:
  lowercase with words separated by
  underscores as necessary to improve
  readability.

就我个人而言，我偏离了这一点，因为对于我自己的项目，我也更喜欢mixedCase而不是lower_case。

编码风格通常是组织内部政策/惯例标准的一部分，但我认为一般来说，all_lower_case_underscore_separator风格(也称为snake_case)在python中最为常见。

如其他答案所示，有PEP 8，但PEP 8只是标准库的样式指南，在其中仅作为福音。 PEP 8对于其他代码段最常见的偏差之一是变量命名，尤其是方法。尽管考虑到使用mixedCase的代码量很大，但没有单一的主导风格，如果要进行严格的普查，则可能最终会得到带有mixedCase的PEP 8版本。与PEP 8几乎没有其他偏差是很常见的。

大多数python的人都喜欢使用下划线，但是即使是从5年前开始使用python，我仍然不喜欢它们。它们对我来说看起来很难看，但也许这就是我脑海中的所有Java。

我只是更喜欢CamelCase，因为它更适合于类的命名方式。与SomeClass.do_something()相比，SomeClass.doSomething()更具逻辑性。如果我们在python中查看全局模块索引，则会发现这两者，这是由于它是随着时间推移而增长的来自各种来源的库的集合，而不是由像Sun这样的公司开发的具有严格编码规则的库。我要说的底线是：使用任何我们喜欢的更好的东西，这只是个人品味的问题。

我个人尝试将CamelCase用于类，mixedCase方法和函数。变量通常用下划线分隔(当我记得时)。这样一来，我就可以一目了然地告诉我我到底在叫什么，而不是所有看起来都一样的东西。

David Goodger(在"像Pythonista的代码一样"中)描述了PEP 8的建议，如下所示：

• 函数，方法，属性，变量的" joined_lower"
• joined_lower或者ALL_CAPS常量
• 类的StudlyCaps
• camelCase仅符合先前的约定

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

如前所述，PEP 8表示将lower_case_with_underscores用于变量，方法和函数。

我更喜欢对变量使用lower_case_with_underscores，对方法和函数使用mixedCase使代码更明确和可读。因此，遵循Python Zen的"显性优于隐性"和"可读性很重要"

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

The naming conventions of Python's
  library are a bit of a mess, so we'll
  never get this completely consistent

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

由此，以及在这里的讨论，我可以推断出，如果人们继续使用例如过渡到Python时，Java或者C＃(明确和完善的)变量和函数的命名约定。当然，请记住，最好遵守代码库/项目/团队的流行风格。正如《 Python风格指南》指出的那样，内部一致性最重要。

随意将我视为异端。 :-)像OP一样，我也不是" Pythonista"，无论如何还不是。