Understanding Namespaces

00:00 In the previous lesson, I showed you the problems with relative imports. In this lesson, I’ll introduce you to implicit namespace packages.

00:09 Just because Python uses the directory structure for package information doesn’t mean that all languages do. For example, Java packages sort of use directory structure, but then allow overlap. To try to have universal package names Java asks that you use the reverse of a domain name that you control.

00:27 So Real Python could use com.realpython with packages inside of it. It would then be up to us at Real Python to make sure that we don’t stomp on each other.

00:36 That said, the way of expressing the structure is through directories, so it’s kind of in between.

00:43 Some languages are more declarative. What if you wanted all packages having to do with networks to be in the same namespace, even if different people are creating the content?

00:53 PEP 420, so hard not to make a joke, introduced implicit namespace packages and they were accepted and included in Python 3.3. This defines a way of grouping things together in the same namespace, even if the component parts are in different directory structures.

01:10 The way you can differentiate a regular package from a namespace package is the __init__.py file. Namespace packages don’t use them.

01:19 I’ve actually never used this feature myself, and most examples that I’ve come across feel a little convoluted to me, but the language supports it, so let’s take a look. Another lesson, another tree of files.

01:32 The parent here, nspace is irrelevant. That’s just me keeping this example separate from the others. The interesting parts here are project1 and project2.

01:41 Both projects have cats/ directories each with their own Python files. Note that none of these directories have __init__.py files, so nothing here is a regular package.

01:53 The meow.py script doesn’t do much besides import from the namespace packages, so it’s hanging out there in the parent directory.

02:01 Let’s look at the kitty files. First, tiger.py, which from its perspective is in the cats namespace. Not much to see here and to go with our tiger is a lion, which is also in the cats namespace.

02:16 Again, the key to this working is there is no __init__ .py file. Out at the root, I have meow.py. This file is similar to the getbox and getgift scripts in previous lessons.

02:30 The first thing it does is add the project1 and project2 directories to the module path. Then, it simply imports the tiger and lion modules.

02:39 Let’s try this out. And that’s pretty much it. On its own it isn’t anything terribly exciting, but if you think back to the lesson on shadowing, you’ll remember you can’t do this with a regular module. With a regular module once cat got loaded, that would’ve been it.

02:55 Like I said, I’m not sure how important this feature is. It often gets mentioned with things like plugins, but I’ve never felt that plugins have to be in the same package namespace.

03:05 I have had this feature bite me once or twice. Because this is automatic if you forget the __init__.py file, you’re in namespace package mode.

03:14 Most of the time, that’s not a problem, but there are subtle differences between it and regular mode, and those subtle differences might bite you if you’re doing something particularly complicated.

03:24 When showing you shadowing, I briefly talked about the idea that the module gets loaded once. That’s because Python uses a cache for your imports. In the next lesson, I’ll show you where it is and how to get around it.