Part V concludes with a collection of more
advanced module-related topics, along with the standard set of
gotchas and exercises. Just like funtions, modules are more effective
when their interfaces are defined well, so this chapter also takes a
brief look at module design concepts. Some of the topics here, such
__name__ trick, are very widely used,
despite the word “advanced” in this
As we’ve seen, Python modules export all names assigned at the top level of their file. There is no notion of declaring which names should and shouldn’t be visible outside the module. In fact, there’s no way to prevent a client from changing names inside a module if they want to.
In Python, data hiding in modules is a convention, not a syntactical constraint. If you want to break a module by trashing its names, you can, but we have yet to meet a programmer who would want to. Some purists object to this liberal attitude towards data hiding and claim that it means Python can’t implement encapsulation. However, encapsulation in Python is more about packaging than about restricting.
As a special case, prefixing names with a single underscore (e.g.,
_X) prevents them from being copied out when a
client imports with a
from* statement. This really
is intended only to minimize namespace pollution; since
from* copies out all names, you may get more than you bargained for (including names that ...