Using Wildcard Imports

00:00 So what are wildcard imports? Wildcard imports bring in all public names from a module. The syntax is from module import *. This imports every public name from a module into the current namespace.

00:13 It uses an asterisk, or star, as a wildcard, and is useful when you need everything a module provides. Which is not really that often. Wildcard imports are rarely recommended in real projects and are actually discouraged by official Python style guidelines, since, if you’re not careful, you can end up inadvertently dumping a bunch of unneeded names into your namespace.

00:35 That being said, no recommendation applies in all cases, and there are even libraries out there designed to be imported this way. So, given all of this, you can also expect some users of your packages and modules are probably going to use wildcard imports too. So, how can you control what’s actually imported?

00:52 The first step is to look at the term public. Since you can’t actually designate code objects as private in Python, Python uses naming conventions to distinguish your intent.

01:04 Names starting with a single underscore are treated as internal to a module, class, or function. So, public names look like foo or spam, while non-public names look like _bar and _ham. But the important thing is, wildcard imports will not include any of these non-public names. As a side note, Python has a long history of using underscores this way. To learn more, check out “Single and Double Underscores in Python Names.” Now let’s take a look at wildcard imports in action. Back in the IDE, we have the calculations module from the last lesson.

01:41 But it looks a little different now. We’ve added a function called circumference, which also uses the constant pi, which has to be imported from the math module.

01:50 So, open the REPL and try a wildcard import.

01:56 from calculations import *. And call dir().

02:00 Okay, you see all five functions have been imported. But so has pi. Weird, but because it’s imported at the top level, it’s also public. See how quickly the namespace can become cluttered unintentionally?

02:14 To prevent this, you’ll need to update calculations.py.

02:19 Close the REPL for now. Use an alias to import pi as _pi. And don’t forget to change the name in the circumference function.

02:28 And just for fun, why don’t we also make add non-public. _add. Hit save.

02:36 Open the REPL again.

02:41 And try the wildcard import once more. from calculations import *.

02:47 Run dir(). And now, only circumference, divide, multiply, and subtract appear. Because they’re considered private, add and pi are no longer imported.

02:58 Okay, perfect. I guess now all you have to do in the future is add underscores to everything you think shouldn’t be imported.

03:05 Not quite. That will work for small modules or scripts, but it becomes unwieldy about as quickly as you’d expect. If only there were a way to designate all the objects that should be imported.

03:19 Learn more in the next lesson.