def, class, and the block

Right. The actual answer to the actual question, before anything else.

def is for functions. class is for classes. Variables have no keyword at all: you just assign to a name.

MAX_RETRIES = 3          # a variable. No let, no const, no var. Just a name and a value.

def send(payload):       # a function.
    return post(payload)

class Sender:            # a class.
    pass

That is the whole thing you could not remember, and it is worth noticing how little there was to remember. This lesson is the rest of the spelling table, because the same shape of gap is sitting behind about fifteen other keywords, and every one of them is a five-second fix that costs you twenty minutes when you hit it cold in someone else’s repo.

The block is whitespace, and the colon opens it

No braces. A colon at the end of a line says a block starts here, and the block is everything indented under it.

def classify(score):
    if score > 90:
        return "excellent"
    elif score > 50:
        return "fine"
    else:
        return "bad"

Four things in that snippet worth naming:

• elif, not else if. It is one word and it is not optional. else if on one line is a syntax error.
• Four spaces. Not a rule of the language, which accepts any consistent indentation, but the entire ecosystem does four spaces and every formatter enforces it. Do not be interesting here.
• No semicolons. They are legal as statement separators and nobody uses them.
• No parentheses around the condition. Legal, pointless, and the formatter will not remove them, so they will just sit there advertising that you came from somewhere else.

And when a block must exist but has nothing in it, you write pass. It is the {} you cannot write, and it does nothing at all, deliberately.

Functions

def request(url, method="GET", *, timeout=30, retries=2, **headers):
    ...

url is required and positional. method has a default. The bare * says everything after me must be passed by keyword, which is how library authors keep a nine-parameter constructor callable without a mystery-argument minefield. **headers collects any leftover keyword arguments into a dict, and *args (which is not in that signature) collects leftover positional ones into a tuple.

The caller side is where Python is genuinely nicer than what you are used to:

request("https://example.com", timeout=5, retries=0, Authorization="Bearer ...")

Every function in Python takes named arguments, for free, without the author designing an options object. This is why Python APIs have long flat signatures where a TypeScript API would take a config object: the language already gave them the ergonomics you were building the object for.

Two more small things:

• return with no value, or falling off the end, both give None. There is no undefined.
• ... is a real expression (it is the Ellipsis singleton) and is idiomatic as a body placeholder in stubs and protocols. pass is the general-purpose one; ... reads as deliberately unimplemented.

Everything that is a symbol in TypeScript and a word in Python

This is the table. It is short, and it is most of your fluency gap.

Scope, and the thing that will bite you

Python has function scope and module scope. There is no block scope.

def handle(items):
    for item in items:
        latest = item          # bound inside the loop
    return latest              # ...and still visible here

That is legal and it does what it looks like. It is also a live grenade: if items is empty, the loop body never runs, latest was never bound, and the return raises UnboundLocalError at runtime. TypeScript would have refused to compile this. Python will happily ship it and fail on the one input where the list came back empty.

nonlocal and global exist to write to a name from an enclosing scope, and you will see them roughly never in application code.

Naming, because the ecosystem is unusually strict about it

snake_case for functions, variables, methods and modules. PascalCase for classes. SCREAMING_SNAKE for constants. This is not taste, it is PEP 8 and every linter in the language enforces it, so camelCase in a Python file reads exactly the way snake_case reads in a TypeScript file.

And there is no private. The convention is a leading underscore meaning internal, do not touch, enforced by nothing but manners. A double leading underscore triggers name mangling inside classes, which is a different and rarer thing you can safely ignore for now.

Imports, and the bottom of every file

import json                          # the whole module. json.loads(...)
from pathlib import Path             # one name out of a module. Path(...)
from typing import Any, Optional     # several names
import numpy as np                   # aliased

def main():
    ...

if __name__ == "__main__":
    main()

That last block is the closest thing Python has to a folk ritual, and it is worth understanding rather than copying. __name__ is a string every module carries. It is the module’s import name normally, and the literal "__main__" when the file is the one being executed directly. So the block means run this only when this file is the entry point, not when someone imports it. Without it, importing your script to reuse one function would run the whole thing.

Where this goes

You now have the shape of a Python file and the spelling of every keyword you will type in the first hour. The next lesson does the data structures, which is where Python starts being noticeably better than what you are used to rather than merely different.