This lesson explains what imports are and goes on to cover the different ways of importing Python modules. You’ll also learn the following from the lesson:
dir() function to inspect imported modules
00:00
Let’s quickly launch up a Python interpreter and see what we’re talking about here. So, when you do import, it’s a simple statement you write at the top of your file to get some extra functionality contained in different modules. So for example, if you were to import a module called module, you’re going to get an ImportError saying that there’s no module named module. Now, in the case that we do have a module that does exist, the import goes through fine. It passes through.
00:23
But what actually happened here? Let’s just quickly back out and run another interpreter, so we’ve reset everything back to whatever’s in our sys path.
00:32
And we’re going to import sys now,
00:36
and then we’re going to go sys.modules.
00:39
As you can see, various things from my virtual env have been passed in. You can see that Python standard library stuff has been brought in, you can see that there are things that courtside depends on have been passed in since I ran the interpreter from the root directory of courtside.
00:57
So, let’s import delorean again now. As you can see, it’s nowhere to be found now. We’re going to do that. And then we’re going to run sys.modules again. As you can see, this is bloated much larger than before.
01:11
So by that simple import of delorean, what happened was that delorean depends on a library called pytz, as well as another library called python-dateutil,
01:23
which it uses internally to get things done. So, as you can see here, those are both imported into our sys.modules path, so that we know when delorean calls something, it can rely on that particular thing.
01:35
So as you can see, pytz, dateutil, so on and so forth. You’re just going to have to take my word for it because it’s quite blurry here.
01:44
But that’s that. What actually happens to our scope, though? With dir(), which is an interesting command, it lets us know what can be called on a particular object, and if nothing is passed in, it shows us our particular scope.
01:57
So, when dealing with scope things, you can see that I’ve imported delorean and sys, which are two different modules that are provided. sys is provided in the Python standard lib, delorean is a library that I wrote that’s installed currently in our virtual env, which is in our system path.
02:12
So, dir() is really handy when doing stuff like that. You can also call dir() on things like delorean, and that’ll let me know what particular things that delorean imported when that happened.
02:21
So you can see that there are the daily variations of particular types of variables, as you can see here, a couple of exceptions, and a couple of functions that I deemed should be around or should be available when you import delorean.
02:36
So, the main thing that we want to see, though, is that an actual Delorean object is there, and that’s what we’re going to actually end up doing stuff with.
02:43
In order to get access to that, we have to go delorean.Delorean(). That returns a datetime object called Delorean.
02:52
If we were to go ahead and get out of here again and come back in, what we could do without having to bloat all of our path, what we could do simply is just go from delorean—so, from our module delorean, import the Delorean class.
03:09
What that does is simply pass the class and put that in our scope. So as you can see, the delorean module is no longer here. All you see is the Delorean class that’s being passed in. Again, you have to remember that delorean is part of a module and that module needs to be included for Delorean to be actually used. So when we take a look at—also, we’re going to have to import sys again. We’re going to go sys.modules.
03:35
You’ll see that it imported everything that it did when it was using delorean, when we did the import for delorean. So that’s another way.
03:41
The from syntax allows us to import the module into our sys thing, but not have the whole module in our scope—just what we asked for in our scope.
03:49
So, you can say a similar thing here for importing multiple things from the particular library. So as we saw before, we had from delorean import, we had a HOURLY syntax there too.
04:04
So when we do our dir() now, you’ll see that Delorean and the HOURLY variable are both in our syntax too. You can do these on multiple lines as well, you can do something like this even, that’s also legal.
04:14
So that’s the reason why you’d want to use from. It minimizes the scope and allows you to target in on things you only need. Now, the converse of this particular thing is delorean import *.
04:28
Now what this does, it bloats our scope and imports everything that delorean initializes or contains that doesn’t begin with an underscore (_).
04:37
And that’s just the syntax that’s generally enforced in the Python community. So now when we do dir(), you’ll see that we have all the things that we had when we did the direct import like we did previously. So you really, really should not ever do something like this, import *.
04:54
This will just bloat your space and if you have multiple of these in succession, these will overwrite different types of things. So for example, if I were to redefine in another package what HOURLY meant, the one that was imported most recently will be the one that HOURLY is set to, which can lead to a bunch of hairy issues and complex headaches.
05:14
Now, another way of importing… Let’s start up another terminal, just so we’re clear. import sys, and we’re also going to do something a little bit like this.
05:23
We’re going to call this variable called delorean, and then we’re going to go = __import__(), and then you pass the string name of the module you want to import.
05:35
So we’re going to go 'delorean.Delorean', and that is the path from the delorean package to the Delorean class.
05:51 Nope, goofed up there. You can only do this like this,
05:56
like so. So when we do our dir(),
06:00
you will have 'delorean' in the thing. And you will also have in your sys.modules, the modules, the entirety of the scope as well.
06:09
So, those are a few ways to import and generally a good way to keep your imports together, so they aren’t bloating or blowing up your stack. And you want to keep your whatever’s in scope as clean as possible, and your sys.modules will be maintained on their own, but it’s a good way to look when you’re having issues when debugging.
Abhishek Saha on March 15, 2019
Really cool explanation. I’m new to python , just having basic Q - How I get to know the required module name for my work. I’m from Windows Powershell background , so whenever I need to do anything , can use find-module azure - mean I dont know what the exact module name but just using this trick , can pull all available module to import or install. Same way to explore listed commands and respective syntax available for commands. How to do this in Python, pls suggest
cyberladysj on Nov. 6, 2019
Thank You Mahdi, this tutorial is excellent! I am still new to python and using python for my Cyber-sec tools. I was trying to import a module and kept getting “‘module’ object has no attibute” and this showed me how to import the module. Thank you again!
vincentstclair on Aug. 11, 2020
This is all over the place. Plan some structure and stop assuming people know what you’re talking about and explain the details. Come on
rjc on July 17, 2023
Please update to python 3…version two has been deprecated for years…
Become a Member to join the conversation.
Bill on March 14, 2019
You have to use modules that we all have access to.