Question

这是另一个和作用域相关的问题：尽管我们能够直接修改另一个文件中的变量，但是往往我们都不这样做。本书下一部分将更深入地讨论第3章中介绍的模块文件。为了说明它们与作用域之间的关系，考虑下面这两个模块文件：

第一个模块文件定义了变量X，这个变量在第二个文件中通过赋值被修改了。注意，我们必须在第二个文件中导入第一个模块才能够得到它的值：就像我们学到的那样，每个模块都是自包含的命名空间（变量名的封装），而且我们必须导入一个模块才能在从另一个模块中看到它内部的变量。这是关于模块的一个要点：通过在每个文件的基础上分隔变量，它们避免了跨文件的名称冲突。

事实上，按照本章的主题来讲，一个模块文件的全局变量一旦被导入就成为了这个模块对象的一个属性：导入者自动得到了这个被导入的模块文件的所有全局变量的访问权，所以在一个文件被导入后，它的全局作用域实际上就构成了一个对象的属性。

在导入第一个模块文件后，第二个模块就将其变量赋了一个新的值。那么，这个赋值的问题就在于，这样的做法过于含糊了：无论是谁负责维护或重用第一个模块，都不一定知道有一个不知道在哪的模块位于导入链上可以修改X。实际上，第二个模块可能在完全不同的一个目录下，而且很难找到。

尽管这样的跨文件变量在Python中总是可能修改的，但它们通常比我们想要的更微妙。再者，这会让两个文件有过于强的相关性：因为它们都与变量X的值相关，如果没有其中一个文件的话很难理解或重用另一个文件。这种隐含的跨文件依赖性，在最好的情况下会导致代码不灵活，最坏的情况下会引发bug。

这里再说一次，最好的解决办法就是别这样做：在文件间进行通信最好的办法就是通过调用函数，传递参数，然后得到其返回值。在这个特定的情况下，我们最好使用accessor函数去管理这种变化。

这需要更多的代码，但是这在可读性和可维护性上有着天壤之别：当人们仅阅读第一个模块文件时看到这个函数，会知道这是一个接入点，并且知道这将改变变量X。换句话说，它删除了令人惊讶的元素，在软件项目中过多地使用它们并非好事。虽然我们无法避免修改文件间的变量，但是通常的做法是最小化文件间变量的修改。