Intro to Python

15. Libraries

One of the core reasons humans thrive on Earth is our unique ability to communicate with each other using language. We use language to share knowledge and build on our predecessors' work to create progress.

Libraries are the programming equivalent of passing essential knowledge down. They store important previously-written code that most programmers are bound to use at some point. However, in terms of how they are used, a programming library is less like a brick-and-mortar library and more like a car. When people sit in a car, they assume the brake pedal will slow the vehicle down, the gas pedal will speed it up, and the wheel will turn it. However, most people do not understand the underlying mechanisms that make those actions possible. This lack of understanding doesn’t hinder the driver. In fact, it helps the driver because they don’t need to know how each of the tens of thousands of moving parts in the car affects its motion. Instead, they just need to understand how two pedals, a lever, and a wheel affect the car’s motion. Drivers can assume the underlying parts work and focus on their primary goal of getting from point A to point B. Soon, self-driving cars could reduce the level of understanding necessary to drive a car even further into just identifying the destination.

Programming libraries are very similar. They package and hide away the complex moving parts so the programmer can focus on “driving.” Libraries enable programmers to focus on big-picture ideas while assuming the small details will be executed flawlessly.

Libraries must be imported first before being used. This is because hundreds of libraries cover thousands of use cases that programmers do not want to worry about (e.g., random number generation, reading files, advanced math, app development, etc.). All of these libraries can be useful yet include a ridiculous amount of code, and forcing your computer to load all of them every time you run a program is resource and memory-intensive. Therefore, most programming languages simply package important code into libraries that can be imported when you need them instead of all the time.

Note: Important libraries such as the String library are imported automatically because they are used in the vast majority of applications.

Let’s take a look at an example. The “String” library is used to store and manipulate text. You can perform many useful operations with it. In Python, the String library is imported by default.

We can do a variety of things using the String library:

  • Adding strings together
a = "Hello "
b = "World!"
c = a + b
> Hello World!
  • Turning all the characters lowercase
a = "Hello World!"
b = a.lower()
> hello world!
  • Find a specific character (in this case the 5th character because strings, like arrays, are 0-indexed)
a = "Hello World!"
b = a[4]
> o

These operations would usually take tens or hundreds of lines of code to perform. However, because previous developers wrote the code for these operations and packaged it into the String library, modern programmers can perform these complex operations with a single line of code. So instead of worrying about whether their string-adding algorithm works, programmers today can focus on addressing far more complicated problems and leave the finer details to their predecessors’ code. See the “Functions” article for how you can build libraries that future programmers will rely on.

It’s clear libraries have many pros. However, there is one major con that every programmer should be aware of (but in most careers will not need to worry about): libraries are not flexible. Using the earlier car analogy, hiding the tiny moving parts can help the programmer focus on the overall goal. But what if the overall goal requires the programmer to focus on the tiny moving parts? You can think of this as fine-tuning a car for speed. Ideally, a driver should remove unnecessary parts from the vehicle (e.g., air conditioning, CD player) to maximize speed. Restricting a driver to only using the pedals, wheel, and stick will bottleneck it. Similarly, programmers who use libraries lose the flexibility of removing unnecessary code or fine-tuning the code because the library hides it away. Programmers who need ultra-fast code need to delve deeper than surface-level libraries (which are generally designed to be fast, but not ultra-fast) in search of performance gains.

You can play with all the code we've used in this article on Trinket: