在python这样的语言中，通过使用较短的变量名，在内存和速度方面有什么好处吗？
如果是这样的话，在什么情况下考虑这一点是合理的？
注意
我绝不提倡短变量名，我只是想知道，请（重新）阅读这个问题。
注意2请注意，我确实理解描述性变量名称的价值。我已经看了足够多的代码，更喜欢描述性的名字而不是较短的名字，并理解了它的价值。
编号。编号编号编号
没有
使用可读的名称，而不是简短的名称。性能差异是完全可以忽略的。
$ python -m timeit "i = 5" "i *= i"
10000000 loops, best of 3: 0.0938 usec per loop
$ python -m timeit "is_there_anything_to_be_gained_from_short_variable_names = 5" "is_there_anything_to_be_gained_from_short_variable_names *= is_there_anything_to_be_gained_from_short_variable_names"
10000000 loops, best of 3: 0.0927 usec per loop
具有讽刺意味的是，当在这台PC上测量时，长变量名称的测量速度因此比每次执行快约0.001 usec。
"like python"有一个问题，因为并非所有解释的语言都是相同的。
对于纯解释语言，它将比Python这样有预编译步骤的语言产生更大的影响。严格来说，这并不是语言上的差异（你可以有一个预编译的Javascript引擎，也可以没有），但它确实会影响这个问题的答案。
把"像蟒蛇一样"延伸到包括每一种解释语言，我会说答案是"是的，对其中一些人来说，至少在某些时候"。下一个问题是"多少"。
从1997年到1998年初，我一直在开发一些相当复杂的javascript代码，这些代码利用了Netscape Navigator 4和Internet Explorer 4的一些新功能。这在当时是一个巨大的javascript文件，当时拨号的流行意味着每千字节都以站点速度为单位。
出于这个原因，我们使用了最小化脚本。这样做的主要目的是将变量重写得更短（lastHeight变为a，userSel为b，依此类推）。
它不仅减少了下载时间，而且使其中一个较重的功能明显更快。但只有当你是一个整天都不看其他事情的人时，这才是值得的，这几乎意味着我和另一位同事。
因此，是的，如果我们把Javascript放在"像python一样"的类别中进行解释，那么它可以在以下条件下产生影响：
- 它在奔腾、奔腾Pro和486s上运行（当时奔腾II已经问世，但我们没有）。在项目进行到一半的时候，我得到了一台新机器，这意味着我从133MHz提高到了166MHz
- 这是一个相当大的令人讨厌的循环（大部分脚本没有明显的差异）
- 它在15年前的脚本引擎上运行，此后脚本引擎的性能没有任何改进
但它仍然没有产生太大的影响。
我们可以假设，其他一些被解释的语言也受到了类似的微小程度的影响。
即使在1997年，如果不是巧合地给了我另一个优势，我也不会介意，而且我肯定没有在最小化的版本上工作。
如果你用"像Python这样的语言"这句话来解释语言，那么是的，这会有所不同，因为解析可能需要更长的时间。我想这种差异是不明显的。
不过，我完全同意《夜莺》；不要这样做。让你的代码对人类可读。让解析器/编译器处理机器的可读性。
记住关于优化的规则：
- 不要这么做
- （仅供专家使用）现在还不做
对于短循环索引和变量为短期变量时，应仅使用短变量名。
否则请使用描述性名称，但不要过度使用，也不要使用匈牙利符号。
几乎没有。诚然，当python预编译脚本时，第一次查找变量名可能会减慢速度。然而，由于短变量名导致的混乱所花费的时间通常远远超过脚本执行过程中节省的时间。
根据orlps的回答，我认为Python类使用字典进行查找，所以我想知道在这方面是否有任何优势。
import timeit
A = """
class A_CLASS_WITH_A_LONG_NAME:
def a_function_with_a_long_name(self):
return 1
A_CLASS_WITH_A_LONG_NAME().a_function_with_a_long_name()
"""
B = """
class A:
def a(self):
return 1
A().a()
"""
print(timeit.timeit(stmt = A, number = 1000000))
print(timeit.timeit(stmt = B, number = 1000000))
我们得到的数字：
- 长=12.362802280999858
- 短=11.444508541899952
两者相差约8%。
在模块内运行（number = 100000000）而不是使用timeit:
- 长=24.87908697128296
- 短=24.695187091827393
两者相差约1%。
我的结论是，内联代码或timeit探查器的复杂性可能存在差异（timeit似乎慢了50倍左右），但Cpython似乎在优化任何差异方面做得很好。我不能说这是否仍然适用于一个有更多成员的类，因为dict会有更多的bucket。