Imports

Importing is how we use other libraries and modules. A library or module is simply a collection of code that exists is not part of the particular program you are writing. There are two ways to install libraries:

Using Pip

Pip is a package management tool that helps install libraries in python. Pip installs these repositories from the internet from their repository. A volunteer group reviews all libraries that are included in pip, and so usually they are pretty secure (about 90%) and reliable. If you use pip, and you install libraries that are well documented, you shouldn't have any problem. The user guide can be found here: Pip

Pip allows you to install packages globally, meaning they are accessible to the python interpreter at a global level. You can also install packages within a local environment. So when you work in a virtual environment and have that environment activated, pip will install the module only to that environment (and you won't be able to access it in other environments). I recommend making use of virtual environments for your projects because it allows pip to manage dependencies more effectively and precisely for that code. It also makes your code more portable. When you install from Pip, please be careful to make sure you have the name of the library correct. There are some malicious libraries out there that have similar names trying to catch people who made typos.

Downloading

You can also install libraries by downloading them directly. In this case, you find the source code and download them to a directory that you know. Usually somewhere inside of your project directory so that they are easily accessible.

If you're installing libraries manually without a package manager, it is totally on you to make sure that the code has been vetted. I'm a little lax when it comes to installing libraries through pip insofar as they are well vetted already, and they're usually libraries that get a lot of use and I've done research on. However, when I install libraries manually, I make sure that I have read and understand every line of code. You can choose what your level of paranoia is, but be aware that whenever you use someone else's library (as you will inevitably do), you're trusting them to have built something that is both safe and not malicious.

Using a library installed through Pip

When you install a library with pip, the setup process makes python aware of that library in the environment that you installed it. So if you installed requests in the global environment (without a virtual environment), then that library is visible and in scope for all of your projects. if you install a library with pip in a virtual environment, that library is available and in scope for the project in that virtual environment. If you get an error with a library that was installed through pip, specifically a name error, then it is highly likely that it was installed in a different scope. So, for each virtual environment, you need to pip install your libraries fresh. This is useful because it means that each virtual environment has a specific version of that library.

Once installed, then you need to import the library. This is as simple as using the import command.

import requests

This will import the requests library. From there, you can call any method that exists in that library. So requests.get("https://www.google.com") will use the get method from the imported requests library passing the string to the method. The method itself takes a URL as a string, makes a request to that address and returns the response it gets from the server.

It is common practice to put all of your import statements at the top of your program file, but there may be some imports that only get made if certain conditions are satisfied. In that case, you can put the import statement anywhere. Just be aware that you can only use the imported library in lines in the file below where you import the library.

Using libraries installed manually

If you install a library manually, you still use import, but the name that is imported is trickier. You need to point the interpreter directly to the directory where that library was installed. If the library is a single file, then you can reference it by name as import foo In this case, the interpreter will look for foo in the same directory that your script is. It will import that code. If you have a multifile library (or a package) then you'll need to import from the directory various scripts.

Import from

In larger libraries, you'll likely only import elements that you're using. In this case, you'll see in tutorials and samples the line from foo import bar which means from the foo package import the program/class bar. Then to run functions in bar you write bar.function_name()

You might also run into cases where you want to import a few functions or a lot of functions. In this case, you can use wildcards to define the specificity. I recommend taking a look at the documentation on import which can be found here.

Style

Time for a little style:

There are many style guidelines out there, and Python publishes a very solid one. I bring this up now because you're probably starting to encounter forums where people offer Python snippets and solutions. This is great, and I strongly encourage you to start looking at other people's code to get a sense of how they solved the problem. At the same time, on those forums you've probably also encountered people with strong opinions about how a problem should or should not be solved. Pythonistas are pretty friendly, so the forums generally remain civil, but there are a lot of opinions out there, especially when trying to write programs in as few of lines as possible. It's enough to get one really confused in a hurry. I would recommend avoiding those concerns for now. For now, there's only two things I want to mention about style. The first is the Zen of Python which you should have taken a moment to read early in the quarter but here it is again:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Now that you've read about that, forget about style, and concern yourself with one most important rule: Understand exactly what you code does all the time (ok, maybe not if you're using a popular machine learning library with complex linear algebra...but still, you should have a sense of what's happening).

Why does this matter?

It is totally possible to assemble a pretty complicated app in Python from snippets or little samples of code off StackOverflow without knowing what's happening in the code. This'll work, but is assumes a couple things:

1. The people offering the snippets on StackOverflow know what they're doing.

2. The solutions are up to date and not using deprecated functions.

3. The people offering the snippets are not offering you toxic code intentionally or unintentionally.

4. There may be intellectual property issues at stake.

I doubt the first one is a serious problem, particularly if you pay attention to upvotes. However, I have seen some bad answers there...usually not the highest ranking one, but often up there. In any case, I suggest that borrowing snippets from other's code without knowing what it's doing is a serious liability. Let's take the os library. This library allows you to interact with the operating system, and with a smallish loop can be used to delete all the files on your disk or run shell commands.

In short, our goal is to build cool things, but more important is to gain control over the cool things we build. If we borrow snippets, that's fine, but we really must understand what they're doing and why they're done that way.