Python Is More Than One Thing

“Python is slow.”

You will hear that sentence. You will also hear that Python is wonderful for working with data. Both get repeated with great confidence, and neither one can be answered until you ask which Python the speaker means.

Because the word names four different things.

Four things behind one name

In the last lesson you pressed Run and a total appeared. That took one sentence to describe and four parts to actually do. Here is the same program seen four times over, once for each part that had to agree before it could work.

The Python language is the shared set of rules that makes a piece of text a Python program: how instructions are grouped, what particular words and marks mean. It is an agreement about meaning, not something you can install.

An implementation is software that follows those rules and actually runs the program. CPython is the original, the most maintained, and by far the most used; it is what arrives when people download Python from Python.org. Others exist, built for different environments and different tradeoffs. One of them is running in your browser right now, which is why the last lesson needed nothing installed on your machine.

The standard library is the set of ready-made tools that comes with an implementation. Each piece is a module, a reusable chunk of code for one kind of job: dates, text, files, internet requests, testing. Those arrive in the box, so nobody has to build them again.

A third-party package is an add-on that does not come in the box, made and distributed by someone else. pandas for data work, Django for web applications, and several hundred thousand more. You do not need to remember those two names. Together with the people who maintain them, the packages make up Python’s ecosystem, and it dwarfs the standard library.

Most real programs touch all four. The text follows the language, an implementation runs it, and along the way it calls a few standard-library modules and two or three installed packages.

Now those two sentences can be answered

Go back to “Python is slow.” Slow where? In the language’s design, in the way one implementation runs code, in a particular program somebody wrote badly, or in a package grinding through heavy arithmetic? Those are four different claims, and three of them are not about the language at all.

“Python is excellent for data analysis” comes apart the same way. Most of that excellence lives in community packages rather than in some data command built into the language.

That is not a criticism. A great deal of what sounds like “Python can do that” really means “somebody built a package for that”.

Which cuts both ways. A package can be abandoned, unsafe, wrong for your project, or incompatible with the rest of your work. Someone still has to ask who maintains it and what depending on it will cost in two years. A large ecosystem is a real strength and it is not a guarantee.

One more thing falls out of these layers, and we will return to it twice. A package can be written so that the slow, heavy work happens in a faster language while readable Python instructions direct it. That arrangement explains most of the AI lesson later on, and most of the honest answer about speed.

Nobody designed this in an afternoon

The rules, the main implementation, the included tools, and the community around them were built across three decades by a lot of people who did not always agree.

So why is the language shaped the way it is? Why indentation, why the emphasis on readability, why the eagerness to connect to other software? For that we go back to a researcher in the Netherlands who liked the language he was working with and kept running into the things it would not let him do.

Go deeper

The Python Language Reference introduction explains the split between the language and its implementations. Python’s packaging guide covers the finer distinction between a distribution package and an import package. Both are references rather than beginner tutorials, and both are optional.