PEAK is installed as a set of Python packages, such as peak.binding, peak.naming, and so on, within the top-level peak package space. To help distinguish between the ``public" and ``private" portions of the code, each subpackage includes an "api" module that exports its API classes, functions, constants, and interfaces.
The top-level package also includes an API subpackage, peak.api, which contains each of the other subpackages' API modules, named for the subpackage. In other words, "from peak.api import binding" produces essentially the same result as "import peak.binding.api as binding".
For convenience, you can also use "from peak.api import *" to import all the API subpackages. Then, you can access any peak.binding API class such as Once by simply referring to binding.Once. In this tutorial and all PEAK documentation and code examples, we'll refer to APIs following this convention: major subpackage followed by a dot and the class or function name.
In general, it's most useful to use "from peak.api import *" to access the PEAK API. Not only does this give you immediate access to all the subpackage API modules, this will also import several other useful variables, like the special "NOT_FOUND" and "NOT_GIVEN" objects, and various logging functions like LOG_CRITICAL and LOG_DEBUG.
Experienced Python programmers may wonder whether using this approach will cause all of PEAK to be imported. In fact, it won't, because the peak.api subpackage uses a ``lazy import" mechanism. Individual API subpackages like peak.binding won't actually be loaded until one of their attributes are accessed. This prevents wasteful up-front loading of all the modules and classes. See the source for peak.api.__init__ and the lazyModule function in peak.binding.imports, if you'd like to know more about how it works.