如果只是想要一个独立的程序，以便用户不必预先安装 Python 即可下载和运行它，则不需要将 Python 编译成 C 代码。有许多工具可以检测程序所需的模块，并将这些模块与 Python 二进制程序捆绑在一起生成单个可执行文件。
一种方案是使用 freeze 工具，它在 Python 源码目录的 Tools/freeze 中提供。它能把 Python 字节码转换为 C 数组；一个 C 编译器可以将所有模块嵌入到一个新程序中，然后将其与标准 Python 模块链接。
它的工作原理是递归扫描源代码，获取两种格式的 import 语句，并在标准 Python 路径和源码目录（用于内置模块）检索这些模块。然后，把这些模块的 Python 字节码转换为 C 代码（可以利用 marshal 模块转换为代码对象的数组初始化器），并创建一个定制的配置文件，该文件仅包含程序实际用到的内置模块。然后，编译生成的 C 代码并将其与 Python
解释器的其余部分链接，形成一个自给自足的二进制文件，其功能与 Python 脚本代码完全相同。
下列包可以用于帮助创建控制台和 GUI 的可执行文件:
因为在函数内部某处添加了一条赋值语句，导致之前正常工作的代码报出 UnboundLocalError 错误，这可能是有点令人惊讶。
正常工作，但是以下代码
原因就是，当对某作用域内的变量进行赋值时，该变量将成为该作用域内的局部变量，并覆盖外部作用域中的同名变量。由于 foo 的最后一条语句为 x 分配了一个新值，编译器会将其识别为局部变量。因此，前面的 print(x) 试图输出未初始化的局部变量，就会引发错误。
在上面的示例中，可以将外部作用域的变量声明为全局变量以便访问：
与类和实例变量貌似但不一样，其实以上是在修改外部作用域的变量值，为了提示这一点，这里需要显式声明一下。
你可以使用 关键字在嵌套作用域中执行类似的操作：
函数内部只作引用的 Python 变量隐式视为全局变量。如果在函数内部任何位置为变量赋值，则除非明确声明为全局变量，否则均将其视为局部变量。
起初尽管有点令人惊讶，不过考虑片刻即可释然。一方面，已分配的变量要求加上 可以防止意外的副作用发生。另一方面，如果所有全局引用都要加上 global ，那处处都得用上 global 了。那么每次对内置函数或导入模块中的组件进行引用时，都得声明为全局变量。这种杂乱会破坏
global 声明用于警示副作用的有效性。
假设用 for 循环来定义几个取值各异的 lambda（即便是普通函数也一样）：
以上会得到一个包含5个 lambda 函数的列表，这些函数将计算 x**2。大家或许期望，调用这些函数会分别返回 0 、1 、 4 、
9 和 16。然而，真的试过就会发现，他们都会返回 16 ：
这是因为 x 不是 lambda 函数的内部变量，而是定义于外部作用域中的，并且 x 是在调用 lambda 时访问的——而不是在定义时访问。循环结束时 x 的值是 4
，所以此时所有的函数都将返回 4**2 ，即 16 。通过改变 x 的值并查看 lambda 的结果变化，也可以验证这一点。
为了避免发生上述情况，需要将值保存在 lambda 局部变量，以使其不依赖于全局 x 的值：
以上 n=x 创建了一个新的 lambda 本地变量 n，并在定义 lambda 时计算其值，使其与循环当前时点的 x 值相同。这意味着 n 的值在第 1 个 lambda
中为 0 ，在第 2 个 lambda 中为 1 ，在第 3 个中为 2，依此类推。因此现在每个 lambda 都会返回正确结果：
请注意，上述表现并不是 lambda 所特有的，常规的函数也同样适用。
请在代码文件的首部就导入模块。这样代码所需的模块就一目了然了，也不用考虑模块名是否在作用域内的问题。每行导入一个模块则增删起来会比较容易，每行导入多个模块则更节省屏幕空间。
按如下顺序导入模块就是一种好做法：
为了避免循环导入引发的问题，有时需要将模块导入语句移入函数或类的内部。Gordon McMillan 的说法如下：
当两个模块都采用 "import <module>" 的导入形式时，循环导入是没有问题的。但如果第 2 个模块想从第 1 个模块中取出一个名称（"from module import name"）并且导入处于代码的最顶层，那导入就会失败。原因是第 1 个模块中的名称还不可用，这时第 1 个模块正忙于导入第 2 个模块呢。
如果只是在一个函数中用到第 2 个模块，那这时将导入语句移入该函数内部即可。当调用到导入语句时，第 1 个模块将已经完成初始化，第 2 个模块就可以进行导入了。
如果某些模块是平台相关的，可能还需要把导入语句移出最顶级代码。这种情况下，甚至有可能无法导入文件首部的所有模块。于是在对应的平台相关代码中导入正确的模块，就是一种不错的选择。
只有为了避免循环导入问题，或有必要减少模块初始化时间时，才把导入语句移入类似函数定义内部的局部作用域。如果根据程序的执行方式，许多导入操作不是必需的，那么这种技术尤其有用。如果模块仅在某个函数中用到，可能还要将导入操作移入该函数内部。请注意，因为模块有一次初始化过程，所以第一次加载模块的代价可能会比较高，但多次加载几乎没有什么花费，代价只是进行几次字典检索而已。即使模块名超出了作用域，模块在
请利用函数参数列表中的标识符 * 和 ** 归集实参；结果会是元组形式的位置实参和字典形式的关键字实参。然后就可利用 * 和 ** 在调用其他函数时传入这些实参：
是指出现在函数定义中的名称，而 则是在调用函数时实际传入的值。 形参定义了一个函数能接受何种类型的实参。 例如，对于以下函数定义:
或许大家很想知道，为什么在 y 中添加一个元素时， x 也会改变。
产生这种结果有两个因素：
-
变量只是指向对象的一个名称。执行 y = x 并不会创建列表的副本——而只是创建了一个新变量 y，并指向 x
所指的同一对象。这就意味着只存在一个列表对象，x 和 y 都是对它的引用。
-
列表属于 对象，这意味着它的内容是可以修改的。
在调用 append() 之后，该可变对象的内容由 [] 变为 [10]。由于 x 和 y 这两个变量引用了同一对象，因此用其中任意一个名称所访问到的都是修改后的值
如果把赋给 x 的对象换成一个不可变对象：
可见这时 x 和 y 就不再相等了。因为整数是 对象，在执行 x = x + 1 时，并不会修改整数对象
5，给它加上 1；而是创建了一个新的对象（整数对象 6 ）并将其赋给 x （也就是改变了 x 所指向的对象）。在赋值完成后，就有了两个对象（整数对象
6 和 5 ）和分别指向他俩的两个变量（ x 现在指向 6 而 y 仍然指向
某些操作（例如 y.append(10) 和 y.sort() ）会直接修改原对象，而看上去相似的另一些操作（例如 y = y +
[10] 和 sorted(y) ）则会创建新的对象。通常在 Python 中（以及所有标准库），直接修改原对象的方法将会返回 None ，以助避免混淆这两种不同类型的操作。因此如果误用了
y.sort() 并期望返回 y 的有序副本，则结果只会是 None ，这可能就能让程序引发一条容易诊断的错误。
不过还存在一类操作，用不同的类型执行相同的操作有时会发生不同的行为：即增量赋值运算符。例如，+= 会修改列表，但不会修改元组或整数（a_list += [1, 2, 3] 与
如要知道两个变量是否指向同一个对象，可以利用 运算符或内置函数 。
请记住，Python 中的实参是通过赋值传递的。由于赋值只是创建了对象的引用，所以调用方和被调用方的参数名都不存在别名，本质上也就不存在按引用调用的方式。通过以下几种方式，可以得到所需的效果。
-
这差不多是最明晰的解决方案了。
-
使用全局变量。这不是线程安全的方案，不推荐使用。
-
传递一个可变（即可原地修改的） 对象：
-
传入一个接收可变对象的字典:
-
或者把值用类实例封装起来：
没有什么理由要把问题搞得这么复杂。
最佳选择就是返回一个包含多个结果值的元组。
有两种选择：嵌套作用域、可调用对象。假定需要定义 linear(a,b) ，其返回结果是一个计算出 a*x+b 的函数 f(x)。 采用嵌套作用域的方案如下：
或者可采用可调用对象：
可调用对象的方案有个缺点，就是速度稍慢且生成的代码略长。不过值得注意的是，同一组可调用对象能够通过继承来共享签名（类声明）：
对象可以为多个方法的运行状态进行封装：
假定 x 是一个用户自定义类的实例，dir(x) 将返回一个按字母排序的名称列表，其中包含了实例的属性及由类定义的方法和属性。
一般而言这是无法实现的，因为对象并不存在真正的名称。赋值本质上是把某个名称绑定到某个值上；def 和 class 语句同样如此，只是值换成了某个可调用对象。比如以下代码：
可以不太严谨地说，上述类具有一个名称：即便它绑定了两个名称并通过名称 B 发起调用，可是创建出来的实例仍被视为是类 A 的实例。但无法说出实例的名称是 a 还是 b，因为这两个名称都被绑定到同一个值上了。
代码一般没有必要去“知晓”某个值的名称。通常这种需求预示着还是改变方案为好，除非真的是要编写内审程序。
这就像要知道家门口的那只猫的名字一样：猫（对象）自己不会说出它的名字，它根本就不在乎自己叫什么——所以唯一方法就是问一遍你所有的邻居（命名空间），这是不是他们家的猫（对象）……
……并且如果你发现它有很多名字或根本没有名字，那也不必惊讶！
逗号不是 Python 的运算符。 请看以下例子：
由于逗号不是运算符，而只是表达式之间的分隔符，因此上述代码就相当于：
对于各种赋值运算符（ = 、 += 等）来说同样如此。他们并不是真正的运算符，而只是赋值语句中的语法分隔符。
在 Python 2.5 引入上述语法之前，通常的做法是使用逻辑运算符：
然而这种做法并不保险，因为当 on_true 为布尔值“假”时，结果将会出错。所以肯定还是采用 ... if ... else ... 形式为妙。
可以。通常是在 中嵌套 lambda 来实现的。请参阅以下三个来自 Ulf Bartelt 的示例代码：
请不要在家里尝试，骚年！
函数参数列表中的斜杠表示在它之前的形参全都仅限位置形参。仅限位置形参没有可供外部使用的名称。在调用仅接受位置形参的函数时，实参只会根据位置映射到形参上。假定 是一个仅接受位置形参的函数。 它的帮助文档如下所示：
形参列表尾部的斜杠说明，两个形参都是仅限位置形参。因此，用关键字参数调用 将会引发错误：
要给出八进制数，需在八进制数值前面加上一个零和一个小写或大写字母 "o" 作为前缀。例如，要将变量 "a" 设为八进制的 "10" （十进制的 8），写法如下：
十六进制数也很简单。只要在十六进制数前面加上一个零和一个小写或大写的字母 "x"。十六进制数中的字母可以为大写或小写。比如在 Python 解释器中输入：
这主要是为了让 i % j 的正负与 j 一致，如果期望如此，且期望如下等式成立：
那么整除就必须返回向下取整的结果。C 语言同样要求保持这种一致性，于是编译器在截断 i // j 的结果时需要让 i % j 的正负与
对于 i % j 来说 j 为负值的应用场景实际上是非常少的。 而 j 为正值的情况则非常多，并且实际上在所有情况下让 i
对于整数，可使用内置的 类型构造器，例如 int('144') == 144。 类似地，可使用
如果只是想把字符串转为数字，请不要使用内置函数 。 的速度慢很多且存在安全风险：别人可能会传入带有不良副作用的 Python 表达式。比如可能会传入 __import__('os').system("rm -rf $HOME") ，这会把 home 目录给删了。
还有把数字解析为 Python 表达式的后果，因此如 eval('09') 将会导致语法错误，因为 Python 不允许十进制数带有前导
无法修改，因为字符串是不可变对象。 在大多数情况下，只要将各个部分组合起来构造出一个新字符串即可。如果需要一个能原地修改 Unicode 数据的对象，可以试试 对象或
可以使用 S.rstrip("\r\n") 从字符串 S 的末尾删除所有的换行符，而不删除其他尾随空格。如果字符串 S 表示多行，且末尾有几个空行，则将删除所有空行的换行符：
由于通常只在一次读取一行文本时才需要这样做，所以使用 S.rstrip() 这种方式工作得很好。
类型构造器 tuple(seq) 可将任意序列（实际上是任意可迭代对象）转换为数据项和顺序均不变的元组。
('a', 'b', 'c') 。 如果参数就是元组，则不会创建副本而是返回同一对象，因此如果无法确定某个对象是否为元组时，直接调用 也没什么代价。
类型构造器 list(seq) 可将任意序列或可迭代对象转换为数据项和顺序均不变的列表。例如，list((1, 2, 3)) 会生成 [1, 2,
Python 序列的索引可以是正数或负数。索引为正数时，0 是第一个索引值， 1 为第二个，依此类推。索引为负数时，-1 为倒数第一个索引值，-2 为倒数第二个，依此类推。可以认为 seq[-n] 就相当于 seq[len(seq)-n]。
使用负数序号有时会很方便。 例如 S[:-1] 就是原字符串去掉最后一个字符，这可以用来移除某个字符串末尾的换行符。
原序列不会变化，而是构建一个逆序的新副本以供遍历。
许多完成此操作的的详细介绍，可参阅 Python Cookbook：
如果列表允许重新排序，不妨先对其排序，然后从列表末尾开始扫描，依次删除重复项：
如果列表的所有元素都能用作集合的键（即都是 ），以下做法速度往往更快：
以上操作会将列表转换为集合，从而删除重复项，然后返回成列表。
类似于删除重复项，一种做法是反向遍历并根据条件删除。不过更简单快速的做法就是切片替换操作，采用隐式或显式的正向迭代遍历。以下是三种变体写法：
列表推导式可能是最快的。
列表在时间复杂度方面相当于 C 或 Pascal 的数组；主要区别在于，Python 列表可以包含多种不同类型的对象。
array 模块也提供了一些创建具有紧凑格式的固定类型数组的方法，但其索引访问速度比列表慢。 并请注意 NumPy 和其他一些第三方包也定义了一些各具特色的数组类结构。
若要得到 Lisp 风格的列表，可以用元组模拟 cons 元素：
若要具备可变性，可以不用元组而是用列表。模拟 lisp car 函数的是 lisp_list[0] ，模拟 cdr 函数的是 lisp_list[1] 。仅当真正必要时才会这么用，因为通常这种用法要比 Python 列表慢得多。
多维数组或许会用以下方式建立：
但如果给某一项赋值，结果会同时在多个位置体现出来：
原因在于用 * 对列表执行重复操作并不会创建副本，而只是创建现有对象的引用。 *3 创建的是包含 3 个引用的列表，每个引用指向的是同一个长度为 2 的列表。1 处改动会体现在所有地方，这一定不是应有的方案。
推荐做法是先创建一个所需长度的列表，然后将每个元素都填充为一个新建列表。
以上生成了一个包含 3 个列表的列表，每个子列表的长度为 2。也可以采用列表推导式：
或者你还可以使用提供矩阵类型的扩展包；其中最著名的是 。
这是由两个因素共同导致的，一是增强赋值运算符属于 赋值 运算符，二是 Python 可变和不可变对象之间的差别。
只要元组的元素指向可变对象，这时对元素进行增强赋值，那么这里介绍的内容都是适用的。在此只以 list 和 += 举例。
触发异常的原因显而易见： 1 会与指向（1）的对象 a_tuple[0] 相加，生成结果对象 2，但在试图将运算结果 2
赋值给元组的 0 号元素时就会报错，因为元组元素的指向无法更改。
其实在幕后，上述增强赋值语句的执行过程大致如下：
由于元组是不可变的，因此赋值这步会引发错误。
这时触发异常会令人略感惊讶，更让人吃惊的是虽有报错，但加法操作却生效了：
要明白为何会这样，需要知道 (a) 如果一个对象实现了 __iadd__ 魔法方法，在执行 += 增强赋值时就会调用它，并采纳其返回值；(b) 对于列表而言，__iadd__ 相当于在列表上调用
extend 并返回该列表。因此对于列表可以说 += 就是 list.extend 的“快捷方式”：
a_list 所引用的对象已被修改，而引用被修改对象的指针又重新被赋值给 a_list。 赋值的最终结果没有变化，因为它是引用 a_list 之前所引用的同一对象的指针，但仍然发生了赋值操作。
因此，在此元组示例中，发生的事情等同于：
__iadd__ 成功执行，因此列表得到了扩充，但是虽然 result 指向了 a_tuple[0] 已经指向的同一对象，最后的赋值仍然导致了报错，因为元组是不可变的。
将它们合并到元组的迭代器中，对结果列表进行排序，然后选择所需的元素。
类是通过执行 class 语句创建的某种对象的类型。创建实例对象时，用 Class 对象作为模板，实例对象既包含了数据（属性），又包含了数据类型特有的代码（方法）。
类可以基于一个或多个其他类（称之为基类）进行创建。基类的属性和方法都得以继承。这样对象模型就可以通过继承不断地进行细化。比如通用的 Mailbox 类提供了邮箱的基本访问方法.，它的子类 MboxMailbox、
方法是属于对象的函数，对于对象 x ，通常以 x.name(arguments...) 的形式调用。方法以函数的形式给出定义，位于类的定义内：
请注意 还会检测派生自 的虚继承。 因此对于已注册的类，即便没有直接或间接继承自抽象基类，对抽象基类的检测都将返回 True 。要想检测“真正的继承”，请扫描类的 :
请注意，大多数程序不会经常用 对用户自定义类进行检测。 如果是自已开发的类，更合适的面向对象编程风格应该是在类中定义多种方法，以封装特定的行为，而不是检查对象属于什么类再据此干不同的事。假定有如下执行某些操作的函数:
更好的方法是在所有类上定义一个 search() 方法，然后调用它：
委托是一种面向对象的技术（也称为设计模式）。假设对象 x 已经存在，现在想要改变其某个方法的行为。可以创建一个新类，其中提供了所需修改方法的新实现，而将所有其他方法都委托给 x 的对应方法。
Python 程序员可以轻松实现委托。比如以下实现了一个类似于文件的类，只是会把所有写入的数据转换为大写：
这里 UpperOut 类重新定义了 write() 方法，在调用下层的 self._outfile.write() 方法之前，会将参数字符串转换为大写。其他所有方法则都被委托给下层的
self._outfile 对象。委托是通过 __getattr__ 方法完成的；请参阅 了解有关控制属性访问的更多信息。
请注意，更常见情况下，委托可能会变得比较棘手。如果属性既需要写入又需要读取，那么类还必须定义 __setattr__() 方法，而这时就必须十分的小心。基础的 __setattr__() 实现代码大致如下：
大多数 __setattr__() 实现必须修改 self.__dict__ 来为自身保存局部状态，而不至于引起无限递归。
可以为基类赋一个别名并基于该别名进行派生。这样只要修改赋给该别名的值即可。顺便提一下，如要动态地确定（例如根据可用的资源）该使用哪个基类，这个技巧也非常方便。例如：
Python 支持静态数据和静态方法（以 C++ 或 Java 的定义而言）。
静态数据只需定义一个类属性即可。若要为属性赋新值，则必须在赋值时显式使用类名：
c 自身重载，或者被从 c.__class__ 回溯到基类 C 的搜索路径上的某个类所重载。
注意：在 C 的某个方法内部，像 self.count = 42 这样的赋值将在 self 自身的字典中新建一个名为 "count" 的不相关实例。 想要重新绑定类静态数据名称就必须总是指明类名，无论是在方法内部还是外部:
不过为了获得静态方法的效果，还有一种做法直接得多，也即使用模块级函数即可：
如果代码的结构化比较充分，每个模块只定义了一个类（或者多个类的层次关系密切相关），那就具备了应有的封装。
这个答案实际上适用于所有方法，但问题通常首先出现于构造函数的应用场景中。
在 C++ 中，代码会如下所示：
在 Python 中，只能编写一个构造函数，并用默认参数捕获所有情况。例如：
这不完全等同，但在实践中足够接近。
也可以试试采用变长参数列表，例如：
上述做法同样适用于所有方法定义。
以双下划线打头的变量名会被“破坏”，以便以一种简单高效的方式定义类私有变量。任何形式为 __spam 的标识符（至少前缀两个下划线，至多后缀一个下划线）文本均会被替换为 _classname__spam，其中
classname 为去除了全部前缀下划线的当前类名称。
这并不能保证私密性：外部用户仍然可以访问 "_classname__spam" 属性，私有变量值也在对象的 __dict__ 中可见。 许多 Python 程序员根本不操心要去使用私有变量名。
del 语句不一定调用 __del__() —— 它只是减少对象的引用计数，如果（引用计数）达到零，才会调用 __del__()。
如果数据结构包含循环链接（比如树的每个子节点都带有父节点的引用，而每个父节点也带有子节点的列表），则引用计数永远不会回零。尽管 Python 偶尔会用某种算法检测这种循环引用，但在数据结构的最后一条引用消失之后，垃圾收集器可能还要过段时间才会运行，因此 __del__()
方法可能会在不方便和随机的时刻被调用。这对于重现一个问题，是非常不方便的。更糟糕的是，各个对象的 __del__() 方法是以随机顺序执行的。虽然可以运行 来强制执行垃圾回收工作，但 仍会存在 一些对象永远不会被回收的失控情况。
尽管有垃圾回收器的存在，但为对象定义显式的 close() 方法，只要一用完即可供调用，这依然是一个好主意。这样 close() 方法即可删除引用子对象的属性。请勿直接调用 __del__() —— 而
另一种避免循环引用的做法是利用 模块，该模块允许指向对象但不增加其引用计数。例如，树状数据结构应该对父节点和同级节点使用弱引用（如果真要用的话！）
最后提一下，如果 __del__() 方法引发了异常，会将警告消息打印到 。
返回一个整数，该整数在对象的生命周期内保证是唯一的。 因为在 CPython 中，这是对象的内存地址，所以经常发生在从内存中删除对象之后，下一个新创建的对象被分配在内存中的相同位置。 这个例子说明了这一点：
这两个 id 属于不同的整数对象，之前先创建了对象，执行 id() 调用后又立即被删除了。若要确保检测 id 时的对象仍处于活动状态，请再创建一个对该对象的引用：
身份相等性最重要的特性就是对象总是等同于自身，a is a 一定返回 True。身份相等性测试的速度通常比相等性测试要快。而且与相等性测试不一样，身份相等性测试会确保返回布尔值
但是，身份相等性测试 只能 在对象身份确定的场景下才可替代相等性测试。一般来说，有以下3种情况对象身份是可以确定的：
1） 赋值操作创建了新的名称但没有改变对象身份。 在赋值操作 new = old 之后，可以保证 new is old。
2） 将对象置入存放对象引用的容器，对象身份不会改变。在列表赋值操作 s[0] = x 之后，可以保证 s[0] is x。
3） 单例对象，也即该对象只能存在一个实例。在赋值操作 a = None 和 b = None 之后，可以保证 a
其他大多数情况下，都不建议使用身份相等性测试，而应采用相等性测试。尤其是不应将身份相等性测试用于检测常量值，例如 和 ，因为他们并不一定是单例对象：
同样地，可变容器的新实例，对象身份一定不同：
在标准库代码中，给出了一些正确使用对象身份测试的常见模式：
1） 正如 所推荐的，对象身份测试是 None 值的推荐检测方式。这样的代码读起来就像自然的英文，并可以避免与其他可能为布尔值且计算结果为 False 的对象相混淆。
3） 编写容器的实现代码时，有时需要用对象身份测试来加强相等性检测。这样代码就不会被 float('NaN') 这类与自身不相等的对象所干扰。
缓存方法的两个主要工具是 和 。 前者在实例层级上存储结果而后者在类层级上存储结果。
cached_property 方式仅适用于不接受任何参数的方法。 它不会创建对实例的引用。 被缓存的方法结果将仅在实例的生存其内被保留。
lru_cache 方式适用于具有可哈希参数的方法。 它会创建对实例的引用，除非特别设置了传入弱引用。
最少近期使用算法的优点是缓存会受指定的 maxsize 限制。 它的缺点是实例会保持存活，直到其达到生存期或者缓存被清空。
这个例子演示了几种不同的方式:
上面的例子假定 station_id 从不改变。 如果相关实例属性是可变对象，则 cached_property 方式就不再适用，因为它无法检测到属性的改变。
lru_cache 方式仍然能够适用，但类需要定义 __eq__ 和 __hash__ 方法以便缓存能够检测到相关属性的更新:
当首次导入模块时（或当前已编译文件创建之后源文件发生了改动），在``.py``文件所在目录的``__pycache__``子目录下会创建一个包含已编译代码的``.pyc``文件。该``.pyc``文件的名称开头部分将与``.py``文件名相同，并以``.pyc``为后缀，中间部分则依据创建它的``python``版本而各不相同。（详见 。）
.pyc 文件有可能会无法创建，原因之一是源码文件所在的目录存在权限问题，这样就无法创建 __pycache__ 子目录。假如以某个用户开发程序而以另一用户运行程序，就有可能发生权限问题，测试 Web 服务器就属于这种情况。
除非设置了 环境变量，否则导入模块并且 Python 能够创建``__pycache__``子目录并把已编译模块写入该子目录（权限、存储空间等等）时，.pyc 文件就将自动创建。
在最高层级运行的 Python 脚本不会被视为经过了导入操作，因此不会创建 .pyc 文件。假定有一个最高层级的模块文件 foo.py，它导入了另一个模块 xyz.py，当运行
xyz 是被导入的，但不会为 foo 创建 .pyc 文件，因为 foo.py 不是被导入的。
若要为 foo 创建 .pyc 文件 —— 即为未做导入的模块创建 .pyc 文件 —— 可以利用 和 模块。
模块能够手动编译任意模块。 一种做法是交互式地使用该模块中的 compile() 函数:
这将会将 .pyc 文件写入与 foo.py 相同位置下的 __pycache__ 子目录（或者你也可以通过可选参数 cfile 来重载该行为）。
模块自动编译一个或多个目录下的所有文件。只要在命令行提示符中运行 compileall.py 并给出要编译的 Python 文件所在目录路径即可：
模块可以查看预定义的全局变量 __name__ 获悉自己的名称。如其值为 '__main__' ，程序将作为脚本运行。通常，许多通过导入使用的模块同时也提供命令行接口或自检代码，这些代码只在检测到处于 __name__
问题是解释器将执行以下步骤：
最后一步失败了，因为 Python 还没有完成对 foo 的解释，foo 的全局符号字典仍然是空的。
当你使用 import foo ，然后尝试在全局代码中访问 foo.foo_var 时，会发生同样的事情。
这个问题有（至少）三种可能的解决方法。
Guido van Rossum 建议完全避免使用 from <module> import ... ，并将所有代码放在函数中。全局变量和类变量的初始化只应使用常量或内置函数。这意味着导入模块中的所有内容都以
Jim Roskind 建议每个模块都应遵循以下顺序：
Matthias Urlichs 建议对代码进行重构，使得递归导入根本就没必要发生。
这些解决方案并不相互排斥。
出于效率和一致性的原因，Python 仅在第一次导入模块时读取模块文件。否则，在一个多模块的程序中，每个模块都会导入相同的基础模块，那么基础模块将会被一而再、再而三地解析。如果要强行重新读取已更改的模块，请执行以下操作：
警告：这种技术并非万无一失。尤其是模块包含了以下语句时：
仍将继续使用前一版的导入对象。如果模块包含了类的定义，并 不会 用新的类定义更新现有的类实例。这样可能会导致以下矛盾的行为：
只要把类对象的 id 打印出来，问题的性质就会一目了然：
