Learning Python, 6th Edition

Chapter 25. Module Odds and Ends

This chapter concludes this part of the book with an assortment of module-related topics—data hiding, the __future__ module, the __name__ variable, name-string imports, the __gettattr__ hook, transitive reloads, and more—along with the usual set of gotchas and exercises related to what we’ve covered in this part of the book. Along the way, we’ll build some useful tools that combine functions and modules. Like functions, modules are more effective when their interfaces are well-defined, so this chapter also briefly reviews module design concepts.

Though some coverage here might qualify as advanced and optional, this is mostly a miscellany of additional module subjects. Because some of the topics discussed here are very widely used—especially the __name__ dual-mode trick—be sure to browse here before moving on to classes in the next part of the book.

Module Design Concepts

First up, some perspective. Like functions, modules present design trade-offs: you have to think about which functions go in which modules, module communication mechanisms, and so on. All of this will become clearer when you start writing bigger Python systems, but here are a few general ideas to keep in mind:

• You’re always in a module in Python. There’s no way to write code that doesn’t live in some module. As mentioned briefly in Chapters 17 and 21, even code typed at the interactive prompt (a.k.a. REPL) really goes in a built-in module called __main__; the only unique things ...