How to learn Python properly
Most people learn Python twice. The first time they learn the syntax, follow tutorials, and end up able to write code without being able to read anyone else's. The second time, usually years later and usually because something broke, they learn what was actually happening underneath.
This path does the second one first. Day 1 is how code actually runs, not printing hello world, because everything confusing about Python later is a consequence of something you were never shown at the start.
01 / What learning Python properly actually means
Knowing that a list holds things is syntax. Knowing that a name is a label pointing at an object, so two names can point at the same list and mutating through one changes the other, is understanding. The second one is what stops you filing a bug against the language.
The same split runs through everything. Anyone can write a loop. Knowing that a dict lookup costs the same whether it holds ten items or ten million, and why, is what lets you choose between a list and a dict without guessing.
This is also the part AI tools are least reliable about. They will produce working Python readily. Whether that Python holds up at scale, handles the error case, or does what you meant rather than what you typed is a judgement you have to own.
02 / The order that works
22 days of this path, in sequence
Python carries the first twenty-two days because it gets out of the way, which is what you want while learning ideas rather than syntax. From Day 23 the path moves to JavaScript and TypeScript for the web, and Day 36 comes back to Python for building an API with FastAPI. Seeing the same concept in two languages is the fastest way to stop confusing the concept with the language.
- 01How code actually runs
- 02Values, variables, and what a reference really is
- 03Conditions, loops, and the shape of logic
- 04Functions, arguments, returns, and scope
- 05Lists, dicts, sets, and choosing between them
- 06Errors, exceptions, and reading a stack trace
- 07How to debug anything without guessing
- 08The terminal, files, and paths
- 09Modules, packages, and virtual environments
- 10Git, and why version control exists
- 11Reading unfamiliar code
- 12Everything so far, and your first architecture question
- 13Big O, without the maths
- 14Arrays, strings, and the two-pointer idea
- 15Hash maps, sets, and how caches use them
- 16Objects, classes, and composition over inheritance
- 17Stacks, queues, and the call stack you already met
- 18Recursion, and how it eats the stack
- 19Sorting, binary search, and when you only need the top K
- 20Trees, and why every database index is one
- 21Graphs, BFS, DFS, and dependency order
- 22Your data structure decision table
Every one of those days is free to read in full. See all 90.
03 / Where people go wrong
- 01
Learning syntax instead of the execution model
You can finish a Python course and still not know what happens when you assign one variable to another, why a default argument of an empty list is a trap, or why your loop variable leaked. None of those are advanced. They are all the same missing model of what a name is and what an object is.
- 02
Never reading a stack trace properly
The traceback tells you exactly what happened and most beginners scroll to the bottom, read the last line, and paste it into a search box. Reading it from the bottom up, understanding which frame is yours and which is library code, removes most of the time you currently spend stuck.
- 03
Skipping virtual environments until something breaks
It feels like ceremony until the day two projects need different versions of the same package and your machine can only satisfy one. Understanding what a virtual environment actually isolates takes twenty minutes and saves a category of problem that is miserable to debug.
- 04
Treating data structures as interview material
Choosing a dict over a list is not an interview topic, it is a decision you make several times a day. People who skipped this write code that works at ten items and quietly falls apart at ten thousand, and they usually cannot tell you why.
04 / How long it takes
Twenty-two days at two to three hours, which is the span above. At the end you can read unfamiliar Python and say what it does, debug without guessing, and choose a data structure for a stated reason rather than a habit.
That is not all of Python, and nothing that fits in twenty-two days would be. Decorators, metaclasses, descriptors and the deeper corners of the data model are not here. What is here is the part everything else is built on, which is the part most self-taught routes skip.
05 / Common questions
- Is Python a good first language?
- Yes, mostly because it puts fewer things between you and the idea you are trying to learn. The risk is the same thing: it hides enough that you can write it for years without knowing what it does, which is why this path starts with how code actually runs rather than with syntax.
- How long does it take to learn Python?
- To write useful scripts, a few weeks. To read unfamiliar Python and debug it confidently, which is the actual bar, twenty-two focused days is a realistic target if you are consistent. The variable is not intelligence, it is whether you retrieve the material from memory or only ever recognise it.
- Should I learn Python or JavaScript first?
- This path teaches Python first and moves to JavaScript on Day 23, and that order is deliberate. Python has less incidental complexity, so the foundations land more cleanly. Then meeting the same ideas in JavaScript proves that what you learned was the concept rather than the syntax.
- Do I need Python for AI engineering?
- It helps considerably, since most of the ecosystem is Python-first, though the AI engineering days on this path are largely language agnostic because the hard parts are retrieval, evaluation, cost and failure handling rather than syntax.
The whole path is free and public.
Read the roadmap, open any day, and decide for yourself. Signing in is only so ninety days of progress survives a cleared browser.