Module loading with namespace packages

As mentioned earlier, starting with Python 3.3, it's possible to have a package folder that doesn't contain an init file. Leaving out the init file means we can't support import* or the other tricks within it that we'll discover as we go along. But, there's more to it than that. The following screenshot shows a code example for this:

When the init file is missing, the folder becomes part of a namespace package folder. When Python is importing, it combines all of the namespace package folders it finds, that share a name, into a single logical package, as shown in the following screenshot:

This behavior means that while choosing the module filename, Python still follows the same rules, we could potentially place that file into one of any number of namespace package folders instead of into a singular concrete package folder.

What do we gain from that? Often nothing!

As I mentioned earlier, packages with an init load faster, and in many cases, the extra abstraction of namespace packages doesn't buy us anything.

There are cases, however, when we want different parts of the same package to be distributed or managed separately and when we do, namespace packages address that need. For example, imagine again that we are working on a package for playing soundtracks. If we make a namespace package folder for audio codecs, each codec could be installed and removed individually using pip or the operating system's normal package management tools.

On a slightly different topic, now let's talk about the difference between how a package is structured and the interface it should present for use by external code.