When I was first introduced to Python code, I was knee-deep in a Java project, drowning in boilerplate and semicolons. A friend found a script to do the same thing in about twelve lines. No curly brackets, no type declarations, no public static void main mumbo-jumbo. I believed it to be fake. It was too clean to be run. That was 2016 and I haven’t opened an IDE for Java since then.
Python is a general purpose programming language developed by Guido van Rossum in the late 1980s and first released in 1991. The name is derived from Monty Python, not the snake, which is still a surprise to some. Readability was a central tenet of its design: the code should be nearly English and there should be one right way to do things. It’s debatable whether the community has lived up to that philosophy, but the intent was to create a language that is one of the easiest to learn from scratch.
Much of the reason for the explosion of Python in the past decade is a matter of timing. As data science and machine learning became the most in-demand career on LinkedIn, Python was already there with NumPy, pandas, and scikit-learn. Then TensorFlow and PyTorch decided to make Python the main language for their interfaces, and that was pretty much it. Anyone who wanted to do anything with neural networks was writing Python. It was not the fastest or most elegant language, it was simply the language that the libraries people wanted were built for it, and when others caught up it was too big to ignore.
That’s Python’s best friend and worst enemy. Looking for a web app development? Django and Flask. Automate tedious spreadsheet work? openpyxl and pandas. Scrape websites? BeautifulSoup and Scrapy. Talk to an API? requests does it in 3 lines. The old saying is “There’s a Python library for everything,” and it’s not that far from the truth. There was one package that I found that was just for creating fake restaurant reviews, and it seemed like we’ve gone too far.
However, the pain begins with the installation and maintenance of all those packages. If someone says to you that dependency management in Python is fine, they either don’t know what they are talking about or they have repressed the pain. At some point you will find yourself in a situation where two packages require different versions of the same dependency, and your whole environment comes to a standstill. Virtual environments help — venv, virtualenv, conda, poetry, pipenv — and the number of tools I just mentioned for basically the same problem should tell you all you need to know. Last year I spent an entire afternoon debugging a project that ran fine on my laptop but crashed on my colleague’s because we had different versions of NumPy, just 3 minor releases apart.
The other elephant in the room is speed. Python is slow. Slow in the sense that it doesn’t matter if you’re writing a script to rename files or pulling data out of a CSV, but slow when you’re doing anything computationally intensive in pure Python. This doesn’t kill the language because most of the work is done in C or Fortran under the hood: NumPy, pandas, and PyTorch are all wrappers around compiled code. So you write Python, but the actual number crunching runs at near-native speed. As long as you don’t write nested for-loops over large arrays, you’re safe. As soon as you do, you feel the interpreter tax right away.
This is related to the Global Interpreter Lock — the infamous GIL. It does not allow for true multithreading in CPython, the default Python implementation that most people use. If you require parallelism, you can use multiprocessing, which means you’ll have to deal with the memory overhead of each process, or you can use asyncio for I/O bound tasks. There have been attempts to get rid of the GIL, and PEP 703 added an experimental free-threaded build in Python 3.13, but at the moment it remains optional and most production code has not yet switched to it. In the case of web servers that have to deal with multiple requests at the same time, frameworks such as FastAPI employ async patterns which avoid this problem sufficiently. Most people resort to C extensions or simply give up when it comes to CPU bound parallel work.
The thing that I really like about Python is the lack of friction between the idea and the test. I can open a terminal, type python3 and start playing in the interactive shell in less than a second. No compilation step, no project scaffolding, no XML configuration file. That’s the fastest iteration speed there is for prototyping, exploratory data analysis, or simply to learn how an API works. It’s why Python is the language of choice for Jupyter notebooks, and why it was adopted as the language of choice for teaching introductory computer science at most universities, including MIT, which made the switch from Scheme to Python years ago.
The bad news is that Python code in the wild can be truly horrid. Since the barrier to entry is so low, you get a lot of scripts written by people who learned just enough to get their specific job done and never considered error handling, documentation, or structure. I’ve inherited production code bases where all variables were called x, y, or temp, and the only comment in 800 lines was # fix this later, and it was three years old. The language is not as disciplining as Rust or even TypeScript, and in a large team that can lead to maintenance issues.
Python is free, open source and runs on pretty much anything from Windows to macOS to Linux to Raspberry Pi. No licensing fees, no subscription, no enterprise version. You download it from python.org and away you go. That free starting point, plus the library system and the low learning curve, is what makes it so popular year after year, and always at the top of every programming language popularity list. It’s not the best tool for every job (you wouldn’t use Python to write a high frequency trading engine or a game engine), but for the vast majority of the things that programmers actually do every day, it gets the job done with less suffering than most alternatives. Well, that’s all some days are about.
