A Language Worth Learning

You have decided to learn Python for data work. That is a good decision, and I want to spend a chapter on why before we touch any code, because knowing where a tool came from tells you a great deal about how to use it.

A Christmas Project

In December 1989, a Dutch programmer named Guido van Rossum had a quiet fortnight over the holidays and decided to write a programming language.

He was working at CWI, the national research institute for mathematics and computer science in Amsterdam, on an operating system called Amoeba. The available options for writing administrative tools were unsatisfying. C was too low-level for scripting. The shell was too limited for anything substantial. He had previously worked on a teaching language called ABC, which had wonderful ideas and had failed commercially, and he wanted to take what was good from it and build something practical.

He named it after Monty Python’s Flying Circus, which he had been watching. Not the snake. The snake came later, from publishers who needed a cover image and presumably found a reptile easier to draw than a dead parrot.

The first public release, version 0.9.0, went out in February 1991.

timeline
    title Thirty-five years, abbreviated
    1989 : Guido van Rossum starts over Christmas at CWI, Amsterdam
    1991 : First public release, 0.9.0
    1994 : Python 1.0 — lambda, map, filter, reduce arrive
    2000 : Python 2.0 — list comprehensions, garbage collection
    2008 : Python 3.0 — deliberately breaks compatibility to fix the string model
    2020 : Python 2 reaches end of life after a twelve-year migration
    2021 : Ranked the most popular language in the world by several measures

What Made It Different

Two decisions, both controversial at the time, both now vindicated.

Readability was treated as a feature, not a nicety. Most language design in that era optimised for expressiveness or execution speed. Python optimised for the person reading the code six months later. That sounds soft until you notice that in any long-lived project, code is read far more often than it is written.

Tim Peters wrote the philosophy down in 1999 as a set of aphorisms that ship inside the language itself. Type import this in any Python session and you get them. The relevant ones:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Readability counts.
There should be one-- and preferably only one --obvious way to do it.

That last line is the one that distinguishes Python from several of its contemporaries. Other languages celebrated having many ways to express the same thing. Python considered that a defect, because it means every reader has to learn every dialect.

Indentation is part of the syntax. In most languages, whitespace is decorative and blocks are marked with braces. In Python the indentation is the block structure.

Programmers argued about this for twenty years. The argument is now largely settled, for a simple reason: in every other language, disciplined teams indent their code correctly anyway, and then maintain braces as well. Python removed the second thing and made the first thing enforced. Code that looks right is right, and there is no possibility of the indentation lying about what the braces say.

Python did not win because it was fast, or clever, or academically interesting. It won because a large number of people who were not primarily programmers could read it, and eventually those people outnumbered the programmers.

The Painful Middle

I should be honest about the worst decision in Python’s history, because you will still see traces of it.

Python 3 came out in 2008 and deliberately broke compatibility with Python 2. The core reason was sound: Python 2’s handling of text and bytes was genuinely broken in a way that could not be fixed without breaking things, and it caused a category of bug that plagued every non-English application.

The transition took twelve years. Libraries had to be ported. Companies ran both. Tutorials contradicted each other. Python 2 was finally retired on the first of January 2020.

You have arrived long after this, which is fortunate. Everything in this book is Python 3. If you find a Stack Overflow answer using print without parentheses, it is more than a decade old and you should keep scrolling.

Where Python Is Today

The thing worth understanding is how unusually broad the language’s reach became. Most languages dominate one niche. Python ended up in several unrelated ones at once.

Domain	Examples
Data science and machine learning	Effectively the default. Every major framework ships a Python interface first
Scientific research	The first image of a black hole was produced with Python. So was much of the LIGO gravitational wave analysis
Web backends	Instagram runs one of the largest Django deployments in existence. Spotify, Reddit and Dropbox all built on Python
Infrastructure and automation	Ansible, the AWS command line, and a very large amount of internal glue at almost every company
Finance	Quantitative research desks at most large banks and funds
Education	The default first language at a majority of universities

That breadth has a practical consequence for you. The Python you learn for data analysis is the same Python that automates a report, calls an API, or writes a small web service. You are not learning a domain-specific tool that becomes useless outside its box. Skills transfer sideways, which is unusual and valuable.

By most measures Python has been the most popular programming language in the world since around 2021, and it has appeared near the top of the “most wanted to learn” lists in developer surveys for longer than that. Demand for people who can use it well has not softened.

So, Congratulations

I mean this sincerely rather than as an opening pleasantry.

You have chosen a language that is genuinely pleasant to write, that has the deepest scientific computing ecosystem of anything available, that is in demand across several industries rather than one, and that you can read after a break without needing to reconstruct what you were thinking.

You have also chosen a moment when the material is unusually accessible. The libraries are mature. The documentation is good. The compute you need to learn on is free, in a browser tab. None of that was true fifteen years ago, when learning this meant compiling things and reading academic papers.

The main thing standing between you and competence is time, and the willingness to be bad at something for a few weeks.

How I Learned This, and Why You Should Not Copy Me

I started teaching myself Python in 2011, and I want to describe what that was like, because it explains what this book is trying to be.

There was no obvious place to start. The language had split into two incompatible versions and every tutorial you found was written for one of them without saying which, so half the code you copied simply did not run and you had no way to tell whether the fault was yours. Installing the numerical libraries meant compiling things, and it failed for reasons that required understanding your operating system’s build tools rather than anything about Python. Before Anaconda arrived the following year, getting NumPy and SciPy working on a laptop was genuinely a weekend, and it taught you nothing at all about data.

The learning itself was fragmented. A chapter of a book here, a Stack Overflow answer there, a blog post that assumed six things I did not know. I could get results, and I had no way of judging whether they meant anything. That is the specific gap that self-teaching leaves and it is invisible from the inside, because a model that runs looks exactly like a model that works.

It took me years to notice. What finally closed it was doing the thing properly: a professional certification in machine learning from the University of California, Berkeley. It took me about twelve months.

The value was not the algorithms. I already knew most of those by name. It was the discipline underneath them, and one lesson in particular: my own evaluation had been lying to me for years and I had never suspected it. Learning why a validation score can be confidently wrong was worth more than every technique I picked up on my own.

“Self-teaching gave me the tools and no way to check my own work. That gap took a formal course and twelve months to close, and it is the single reason this book spends so long on evaluation.” — Sameer Gupta

So here is the point of the story. Between 2011 and a certificate is the better part of a decade of scattered reading, dead ends, and confident mistakes. Almost none of that was necessary. It was slow because the material was scattered, because the tooling fought back, and because nobody had told me which parts actually mattered.

That is what I have tried to fix. This book is the path I would have wanted: in order, with the reasoning included, with the tooling problem removed entirely because every chapter runs in a browser tab, and with the parts that actually determine whether your work is any good given the space they deserve rather than a footnote.

You have the material assembled, the compute free, and the mistakes marked out in advance. It should not take you a decade. It should not take you twelve months.

How to Use This Book

Fifteen chapters, arranged in the order the work actually happens.

Getting Started and The Language cover why Python is shaped the way it is, and the specific subset of the language that data work uses constantly. Not a general programming tutorial. The parts that matter here.

The Numerical Stack is NumPy and pandas, the two libraries everything else is built on. These are the longest chapters and the most important. Time spent here pays back everywhere.

Working With Real Data is the unglamorous majority of the job: loading files that fight you, cleaning categories with eleven spellings, joining tables without silently multiplying rows, and drawing charts that answer a question.

Making Claims is the part that separates a result from a number. Statistics you can reason about, and evaluation that does not lie to you. If you read only one section carefully, make it this one.

Modelling and Shipping covers the scikit-learn interface and what it takes to get work out of a notebook and into something that runs on a schedule.

Three suggestions:

• Run the notebooks. Every chapter has one, and it opens in your browser with nothing to install. Reading about an array and printing its shape are different activities and only one of them teaches you anything.
• Break things deliberately. Each notebook ends with exercises designed to fail in instructive ways. Change the numbers. See what happens.
• Do not skip the boring parts. The chapters on evaluation and data cleaning are less exciting than the ones with models in them, and they are where careers are actually made. Everyone can fit a model. Knowing whether the number it produced means anything is the skill.

What You Need

Very little. If you can write a for loop and understand what a function is, in any language, you have enough. If you cannot, chapter three covers it and you will be fine.

You do not need mathematics beyond secondary school to start. Where a chapter needs a concept, it explains it, and it does so with simulation rather than proof wherever possible.

You do not need to install anything to begin. Every chapter’s notebook runs in Google Colab in a browser tab.

Next, the question anyone learning this in 2026 should be asking out loud: whether it is still worth learning to code at all when machines have become good at writing it.