Python Developer Beginner to Expert

Variables, conditionals, loops, functions, default and keyword arguments, and f-strings. Learn why mutable default arguments are a trap, since the default is evaluated once at definition time.

list, tuple, dict, set. Know the cost of each operation: membership testing is O(n) in a list and O(1) in a set, which is the single most useful performance fact for a beginner.

List, dict and set comprehensions, plus generator expressions and the yield keyword. Generators matter because they let you process data larger than memory.

Understand that assignment binds a name to an object rather than copying it, and what that means for lists passed into functions. Learn copy vs deepcopy.

try/except/else/finally, raising and defining exceptions, and why bare except: hides bugs including the KeyboardInterrupt you are pressing.

__init__, __repr__, __eq__, __hash__, and @property. A good __repr__ pays for itself the first time you debug a list of objects.

Implement __iter__/__next__ and __enter__/__exit__. Duck typing means these protocols, not inheritance, are how Python composes.

Write decorators with functools.wraps, including ones that take arguments. You will meet them in every framework before you write one.

dataclasses with slots and frozen for lightweight, immutable models. Reach for these before writing __init__ by hand.

pathlib, collections (defaultdict, Counter, deque), itertools, functools, datetime with timezones, and json. Most "I need a library for this" moments are already solved here.

How Python linearises the class hierarchy and what super() actually does in a diamond. Useful for reading framework code, rarely for writing your own.

Annotate functions and classes, then read the modern syntax: built-in generics (list[int]), the | union operator, Optional, Protocol for structural typing, and TypedDict.

Run mypy or pyright in CI. Start with a loose configuration on new code only; turning strict mode on across a large untyped codebase produces thousands of errors and gets abandoned.

Adopt ruff for both linting and formatting, or black plus ruff. The point is to stop discussing style in code review, so pick one and enforce it in CI.

Understand why isolation is mandatory, and use one tool consistently: venv, uv, or Poetry. Installing into the system Python is how you break your operating system's tooling.

Plain assert statements, test discovery, and running a subset with -k. pytest's assertion rewriting is why its failure output is readable.

Fixtures for setup and teardown with the right scope, and @pytest.mark.parametrize to turn five near-identical tests into one. Watch out for function-scoped fixtures doing expensive work.

unittest.mock and monkeypatch, plus the judgement call: prefer passing a fake in through a parameter over patching a module path, because patched paths break when you move code.

Use coverage to find untested branches, not as a target to hit. A hundred percent coverage of assertions that assert nothing is a metric, not a test suite.

Hypothesis generates inputs you would not have thought of, and shrinks failures to a minimal case. Worth it for parsers, serialisers, and anything with tricky edge cases.

Only one thread executes Python bytecode at a time, so threads do not speed up CPU-bound work. They do help I/O-bound work, because the lock is released while waiting on I/O.

The rule of thumb: threads for I/O-bound work, processes for CPU-bound work. concurrent.futures gives both the same interface, so switching is a one-line change.

async/await, the event loop, asyncio.gather and TaskGroup. Learn the failure mode first: one blocking synchronous call inside an async function stalls the entire loop.

You cannot use requests inside asyncio and get concurrency; you need httpx or aiohttp. Every sync library has this problem, and mixing the two worlds is the usual source of mysterious slowness.

Recent CPython versions offer an experimental build without the GIL. Worth following, and not worth depending on until your dependencies support it.

FastAPI for APIs, where type hints drive validation and docs. Django when you want an ORM, admin, auth and migrations included. Flask when you want to assemble the pieces yourself.

Pydantic for untrusted input, dataclasses for trusted internals. The distinction matters: validation belongs where data enters the system, not everywhere.

SQLAlchemy or the Django ORM, plus migrations with Alembic or Django migrations. Learn to read the SQL your ORM emits, and to recognise the N+1 pattern.

Celery with Redis, or a lighter option like RQ or Dramatiq. Anything slower than a request timeout belongs in a queue rather than a thread you spawned in a view.

httpx or requests with explicit timeouts, and retries with exponential backoff and jitter. A client with no timeout will eventually hang a worker forever.

The single modern configuration file: project metadata, dependencies, and tool settings. setup.py is legacy and you should not start there.

A lockfile pins the entire resolved dependency tree. uv.lock, poetry.lock, or pip-compile output all work. Without one, two installs a week apart give different code.

Build with python -m build, upload with twine, and test on TestPyPI first. Use a trusted publisher from CI rather than a long-lived API token.

Multi-stage builds, installing from the lockfile, running as a non-root user, and avoiding the trap of copying the whole source before installing dependencies and busting the layer cache every build.

Cython, mypyc, or a Rust extension via PyO3 when profiling proves a hot loop is the bottleneck. Profile first, because this is rarely the answer.

Configure the logging module properly with levels and a JSON formatter, writing to stdout. print() is not logging, and it loses you severity, context and timestamps.

cProfile for CPU, tracemalloc for memory, py-spy to profile a running process without restarting it. Measure before optimising, every time.

Read configuration from the environment, validate it at startup so a missing variable fails immediately, and pull secrets from a secret manager rather than a committed .env file.

Bound your database connections, and understand why serverless breaks this: hundreds of concurrent function instances each opening a connection will exhaust the database long before the compute limit.

gunicorn for WSGI, uvicorn for ASGI, often gunicorn managing uvicorn workers. Worker count times threads has to fit both your CPU allocation and your database connection limit.

Sentry for exceptions with context, and OpenTelemetry when you need to follow a request across services. A traceback without the request that caused it is half a bug report.