Reading Over the Machine's Shoulder

What Python is, where it came from, and why you still have to be able to read it.

Jason Newell

July 2026

You type a sentence into a box. Add error handling to every route. Clean this spreadsheet. Write me something that renames a thousand files by the date buried inside them. You press enter, and a few seconds later a block of code appears, indented and quiet, the way Python always looks. A cursor waits underneath it. You run it. It works, or it looks like it works.

The question you stepped over is the small one. Do you know what it just did?

That is the ordinary condition of building software now. You describe the outcome and a model writes the Python, and most of us read that Python the way we read a terms-of-service page, which is to say we scroll. I have done it. I have shipped code I only skimmed. The argument here is narrow and a little old-fashioned. Not so you can write every line by hand. So you can tell whether the machine that wrote it did the job.

Part I. A language small enough to fit on a page

The surprising thing about Python is how little of it you need. The core of the language is a short list of moves: a few commands that read and count and show things, a handful of types for holding data, the words that decide and repeat, a way to bundle steps into a function you call by name, and a way to guard the parts that might fail. Learn those and you can read most of what you will ever meet.

They are worth seeing laid out together, because the order they stack in is most of what a program is.

Figure 1. The core Python commands, their syntax, and how a small script nests them from the first line to the last.

Read the figure from top to bottom and you are reading the shape of an ordinary script. It imports code someone already wrote. It names some data. It defines a function or two, and then it does the deciding and the repeating, the if and the for, with the risky part wrapped in a guard and the answer printed on the last line.

That economy was the point from the start. Python was built on one conviction its creator never let go of: that code is read far more often than it is written, so it had better be easy to read.

If you want to learn to read it, the official tutorial at docs.python.org is free and written by the people who built the language, and Al Sweigart's Automate the Boring Stuff with Python is free online and the gentlest on-ramp there is. To get the shapes into your hands, Exercism's Python track walks you through small exercises with a mentor on call, and LeetCode hands you an endless supply of problems to grind. Reading comes first. The rest is repetition.

Part II. Where you actually meet it

You rarely meet Python in a blank file anymore. You meet it inside an editor with a model wired into it, and the editor is worth a minute, because it is the seat you sit in to talk to your AI.

Most roads start at VS Code, Microsoft's free editor and the one the largest share of developers already use. GitHub Copilot rides inside it as an extension, suggesting the next line as you type, and it runs in most other editors too. It is the cheapest way in and the one the most people have. Cursor took a different route. It is a copy of VS Code with the AI built into the walls instead of bolted to the side, so it can rewrite five files at once from a single instruction. Claude Code lives in the terminal and takes a whole task at a time, closer to handing work to a junior engineer than to autocompleting your sentence. There are open ones too, like Cline, that let you bring your own model and pay only for what it burns.

They differ in shape and price, and the prices move every few months, so no number here is worth memorizing. What they share is the part that matters. You give an instruction in plain English, a model writes Python, and the Python lands in front of you. Which editor you choose decides how the work feels. It does not change the fact that the output is code, and the code is yours to check.

Part III. Thirty-five years of it

The language is older than most of the people now writing it. Guido van Rossum, a Dutch programmer, started it over his Christmas break in 1989 as a hobby, a cleaner successor to a teaching language called ABC, and released the first version in February 1991. He named it after Monty Python's Flying Circus, not the snake, which is why example code is still full of spam and eggs where other languages use foo and bar.

It grew in slow, deliberate steps. Python 2 arrived in 2000, Python 3 in 2008, the second a repair deep enough that it broke compatibility with the first and took the community the better part of a decade to cross. Van Rossum ran the project as its final decision-maker, the benevolent dictator for life, until he stepped down in 2018 and handed it to an elected council. Through all of it the founding idea held. The language should be one a person can read.

Part IV. What it is for

Plenty. Websites and the services behind them. The scripts that hold an office together. The overnight jobs that move data from one place to another. Scientific computing, and a generation of students meeting their first loop. Python is the glue language, the thing you reach for when two systems need to be introduced and neither wants to do the talking.

Then there is the work that made it famous a second time. The tools of modern AI are Python tools. NumPy holds the numbers, pandas holds the tables, scikit-learn does the classic machine learning, and PyTorch and TensorFlow train the deep networks that everything else now rests on. Hugging Face's libraries put a language model a few lines away from anyone who wants one. Python is not a fast language, and it won this ground anyway, because the heavy math underneath those libraries is written in faster languages like C and run on graphics cards, and Python is the plain handle on top that a human can hold. Its creator has put it more strongly than I would. In his telling, AI is what it is today in part because Python was there to build it in.

Part V. The part you cannot hand off

Here is the number that should stop you. In Stack Overflow's 2025 developer survey, more than eight in ten developers said they use AI tools or plan to, and about half reach for them every day, and fewer than a third trust the output to be correct. We have built a habit we do not believe in. An audit of AI-written code by the security firm Veracode landed in the same place from the other side: close to half of it failed a security check, and most of it carried a design flaw of some kind.

That gap is the whole reason to learn the small grammar in that first diagram. It stops being trivia the moment a model hands you something that runs.

Read a for loop and you can see whether it counts one step too far. Read an exception handler and you can see whether it is quietly swallowing the very error that was trying to warn you. Read a function's first line and you can see whether it was handed what it needed, or something close enough to pass and wrong enough to hurt three weeks from now. None of this is advanced. It is the same small set of shapes from the diagram, read instead of written. Writing Python from a blank page is optional now. Reading it well enough to catch a fluent machine being confidently wrong is not.

That is the quiet skill the tools cannot give you, because it is the one that checks them.

What the cursor is waiting for

Go back to the block of code from the start. It is clean. It is indented. It reads like something a careful person wrote, and it may have come from something that has never once run a program and felt it fail. Fluent and correct look identical on the screen. They come apart only when someone reads.

The code sits there, waiting. The cursor blinks under the last line. The only thing between you and whatever it is about to do is whether you can read it.

Then you press enter.