This chapter concludes Part V with a collection of more advanced module-related topics—relative import syntax, data hiding, the
_ _future_ _ module, the
_ _name_ _ variable,
sys.path changes, and so on—along with the standard set of gotchas and exercises related to what we've covered in this part of the book. Like functions, modules are more effective when their interfaces are well defined, so this chapter also briefly reviews module design concepts, some of which we have explored in prior chapters.
Despite the word "advanced" in this chapter's title, some of the topics discussed here (such as the
_ _name_ _ trick) are widely used, so be sure you take a look before moving on to classes in the next part of the book.
As we've seen, a Python module exports all the names assigned at the top level of its 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 it wants 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 fortunately, I've yet to meet a programmer who would. Some purists object to this liberal attitude toward data hiding, and claim that it means Python can't implement encapsulation. However, encapsulation in Python is more about packaging than about restricting.