Lo que me llevé de terminar Python Crash Course

Llevo años shippeando código en JavaScript, TypeScript y Go. Python era el hueco. Me hice Python Crash Course de Eric Matthes de principio a fin, y es uno de los mejores recursos que he usado para pasar de cero a "puedo construir y shippear Python". Estructura clara, sin fluff, y ejercicios que te obligan a teclear código en vez de hojear. Cuando lo terminas, tienes suficiente para escribir scripts, pequeñas herramientas y leer Python de producción con confianza.

Esto es lo que el libro te da al final, una cosa que no enfatiza lo suficiente (entornos virtuales), y algo un poco más avanzado: escribir tu propio context manager para poder usar with con tus propios recursos.

Después de terminar el libro

Para cuando terminas Python Crash Course, ya tienes variables, strings, números, listas, condicionales, loops, diccionarios, input de usuario, while, funciones, clases, archivos y al menos un proyecto (juego, data viz o web app). Tienes f-strings, list comprehensions, .get() y .items(), y el hábito de "corre, rompe, arregla". Los ejercicios son la mezcla justa de guiados y abiertos. Hacerlos todos es lo que hace que se pegue.

Un patrón que rinde en todas partes: acceso seguro a dicts. En código real muchas veces no sabes si una clave existe. Usar dict.get(key, default) en vez de dict[key] evita KeyError. Envolver eso en un helper pequeño para claves anidadas evita que los scripts revienten por datos faltantes —más sobre esto abajo.

Lo que necesitas en el mundo real: entornos virtuales

El libro te pone a escribir Python; no dedica mucho tiempo a dónde lo ejecutas. En la práctica, nunca instalas paquetes globalmente. Usas un entorno aislado por proyecto. Para eso está venv (viene con Python).

Por qué importa venv

Dependencias: El proyecto A necesita requests==2.28, el proyecto B necesita 2.31. Una instalación global no puede satisfacer a ambos.
Reproducibilidad: pip freeze > requirements.txt y pip install -r requirements.txt para que tú y otros puedan recrear el mismo entorno.
Sin polución: Tu Python del sistema queda limpio; nada de sudo pip install ni líos de permisos.

Loop rápido

python3 -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt
# ... work ...
pip freeze > requirements.txt
deactivate

Crear → activar → instalar → freeze cuando cambian deps → deactivate. Cuando eso es memoria muscular, listo.

Acceso anidado seguro: un helper pequeño

Un patrón mínimo para leer claves anidadas de dicts (p. ej. de JSON o respuestas de API) sin crashear por claves faltantes:

import json

def get_nested(data: dict, *keys, default=None):
    """Get a nested key without KeyError. Example: get_nested(d, 'user', 'address', 'city')"""
    for key in keys:
        if not isinstance(data, dict):
            return default
        data = data.get(key)
        if data is None:
            return default
    return data

with open("config.json") as f:
    config = json.load(f)

city = get_nested(config, "user", "address", "city", default="unknown")
print(f"City: {city}")

data.get(key) devuelve None o tu default si falta la clave. Encadenar eso en un loop te da acceso profundo seguro. El type hint data: dict ayuda cuando el script crece.

Súper técnico: escribir tu propio context manager

El libro muestra with open(...) as f. Usas with para que el archivo se cierre aunque haya una excepción. Eso es un context manager. Cuando sabes cómo funcionan, puedes escribir los tuyos para cualquier patrón "setup → uso → teardown": locks, timers, estado temporal, sesiones de API, etc.

Python te da dos formas de implementar uno.

1. Basado en clases: `enter` y `exit`

Cualquier clase que defina __enter__ y __exit__ puede usarse con with:

import time

class Timer:
    """Context manager that prints how long the block took."""
    def __enter__(self):
        self.start = time.perf_counter()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        elapsed = time.perf_counter() - self.start
        print(f"Elapsed: {elapsed:.3f}s")
        return False  # don't suppress exceptions

# Usage
with Timer():
    time.sleep(0.1)
# Elapsed: 0.100s

__enter__ corre al entrar al bloque with; su return es lo que recibes tras el as (p. ej. with Timer() as t:).
__exit__ corre al salir del bloque (normal o por excepción). Los tres argumentos son el tipo, valor y traceback de la excepción; si devuelves True, Python la traga. Devolver False (o nada) la re-lanza.
Aquí solo lo usamos para medir tiempo e imprimir; no suprimimos errores.

2. Basado en generadores: `@contextmanager`

Para casos simples, un generador más contextlib.contextmanager es menos boilerplate:

from contextlib import contextmanager

@contextmanager
def temporary_override(obj, attr, value):
    """Temporarily override an attribute; restore it when leaving the block."""
    old = getattr(obj, attr, None)
    setattr(obj, attr, value)
    try:
        yield
    finally:
        if old is not None:
            setattr(obj, attr, old)
        else:
            delattr(obj, attr)

# Example: temporarily change a config
class Config:
    debug = False

with temporary_override(Config, "debug", True):
    print(Config.debug)  # True
print(Config.debug)  # False again

Todo lo anterior al yield es "setup"; todo lo posterior (en el finally) es "teardown".
El finally garantiza que el teardown corre aunque el bloque lance. Eso es lo que hace seguros a los context managers.
Este patrón aparece en todas partes: mocking en tests, cambiar env vars, adquirir y liberar locks.

Por qué merece la pena saberlo

Cuando sabes escribir un context manager, dejas de repetir try/finally a mano para el mismo recurso. Tienes un solo lugar que es dueño de "abrir/cerrar" o "adquirir/liberar", y quien llama solo escribe with MyResource():. Es la misma idea que with open(...) pero para tus propias abstracciones. El libro no profundiza aquí; aprenderlo por tu cuenta es un buen siguiente paso tras terminar el último capítulo.

Qué sigue

Tras terminar Python Crash Course tienes suficiente para escribir CLI tools, automatizar tareas y leer el Python de otros. Adopta venv y el acceso seguro a dicts pronto; añade context managers cuando empieces a construir cosas que gestionan recursos (archivos, conexiones, locks). Si estás con el libro o vienes de otro lenguaje, esas tres te harán el código más profesional y menos "solo-tutorial".

I’ve been shipping code in JavaScript, TypeScript, and Go for years. Python was the gap. I went through Python Crash Course by Eric Matthes from start to finish, and it’s one of the best resources I’ve used to go from zero to “I can build and ship Python.” Clear structure, no fluff, and exercises that force you to type code instead of skim. Once you finish it, you have enough to write scripts, small tools, and read production Python with confidence.

Here’s what the book gives you by the end, one thing it doesn’t emphasize enough (virtual environments), and something a bit more advanced: writing your own context manager so you can use with for your own resources.

After finishing the book

By the time you finish Python Crash Course, you’ve got variables, strings, numbers, lists, conditionals, loops, dictionaries, user input, while, functions, classes, files, and at least one project (game, data viz, or web app). You get f-strings, list comprehensions, .get() and .items(), and the habit of “run it, break it, fix it.” The exercises are the right mix of guided and open-ended. Doing every one is what makes it stick.

One pattern that pays off everywhere: safe dict access. In real code you often don’t know if a key exists. Using dict.get(key, default) instead of dict[key] avoids KeyError. Wrapping that in a small helper for nested keys keeps scripts from blowing up on missing data—more on that below.

What you need in the real world: virtual environments

The book gets you writing Python; it doesn’t spend much time on where you run it. In practice, you never install packages globally. You use an isolated environment per project. That’s what venv (built into Python) is for.

Why venv matters

Dependencies: Project A needs requests==2.28, project B needs 2.31. One global install can’t satisfy both.
Reproducibility: pip freeze > requirements.txt and pip install -r requirements.txt so you and others can recreate the same environment.
No pollution: Your system Python stays clean; no sudo pip install or permission mess.

Quick loop

python3 -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt
# ... work ...
pip freeze > requirements.txt
deactivate

Create → activate → install → freeze when deps change → deactivate. Once that’s muscle memory, you’re set.

Safe nested access: a small helper

Here’s a minimal pattern for reading nested dict keys (e.g. from JSON or API responses) without crashing on missing keys:

import json

def get_nested(data: dict, *keys, default=None):
    """Get a nested key without KeyError. Example: get_nested(d, 'user', 'address', 'city')"""
    for key in keys:
        if not isinstance(data, dict):
            return default
        data = data.get(key)
        if data is None:
            return default
    return data

with open("config.json") as f:
    config = json.load(f)

city = get_nested(config, "user", "address", "city", default="unknown")
print(f"City: {city}")

data.get(key) returns None or your default if the key is missing. Chaining that in a loop gives you safe deep access. Type hint data: dict helps when the script grows.

Super technical: writing your own context manager

The book shows with open(...) as f. You use with so the file is closed even if an exception happens. That’s a context manager. Once you know how they work, you can write your own for any “setup → use → teardown” pattern: locks, timers, temporary state, API sessions, etc.

Python gives you two ways to implement one.

1. Class-based: `enter` and `exit`

Any class that defines __enter__ and __exit__ can be used with with:

import time

class Timer:
    """Context manager that prints how long the block took."""
    def __enter__(self):
        self.start = time.perf_counter()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        elapsed = time.perf_counter() - self.start
        print(f"Elapsed: {elapsed:.3f}s")
        return False  # don't suppress exceptions

# Usage
with Timer():
    time.sleep(0.1)
# Elapsed: 0.100s

__enter__ runs when you enter the with block; its return value is what you get after as (e.g. with Timer() as t:).
__exit__ runs when you leave the block (normally or by exception). The three arguments are the exception type, value, and traceback; if you return True, Python swallows the exception. Returning False (or nothing) re-raises it.
Here we only use it to measure time and print; we don’t suppress errors.

2. Generator-based: `@contextmanager`

For simple cases, a generator plus contextlib.contextmanager is less boilerplate:

from contextlib import contextmanager

@contextmanager
def temporary_override(obj, attr, value):
    """Temporarily override an attribute; restore it when leaving the block."""
    old = getattr(obj, attr, None)
    setattr(obj, attr, value)
    try:
        yield
    finally:
        if old is not None:
            setattr(obj, attr, old)
        else:
            delattr(obj, attr)

# Example: temporarily change a config
class Config:
    debug = False

with temporary_override(Config, "debug", True):
    print(Config.debug)  # True
print(Config.debug)  # False again

Everything before yield is “setup”; everything after (in the finally) is “teardown”.
The finally ensures teardown runs even if the block raises. That’s what makes context managers safe.
This pattern shows up everywhere: mocking in tests, changing env vars, acquiring and releasing locks.

Why this is worth knowing

Once you can write a context manager, you stop repeating try/finally by hand for the same resource. You get one place that owns “open/close” or “acquire/release,” and callers just write with MyResource():. It’s the same idea as with open(...) but for your own abstractions. The book doesn’t go deep here; learning it yourself is a solid next step after finishing the last chapter.

What’s next

After finishing Python Crash Course you have enough to write CLI tools, automate tasks, and read other people’s Python. Adopt venv and safe dict access early; add context managers when you start building things that manage resources (files, connections, locks). If you’re going through the book or coming from another language, those three will make your code feel more professional and less “tutorial-only.”

Después de terminar el libro

Lo que necesitas en el mundo real: entornos virtuales

Por qué importa venv

Dependencias: El proyecto A necesita requests==2.28, el proyecto B necesita 2.31. Una instalación global no puede satisfacer a ambos.
Reproducibilidad: pip freeze > requirements.txt y pip install -r requirements.txt para que tú y otros puedan recrear el mismo entorno.
Sin polución: Tu Python del sistema queda limpio; nada de sudo pip install ni líos de permisos.

Loop rápido

python3 -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt
# ... work ...
pip freeze > requirements.txt
deactivate

Crear → activar → instalar → freeze cuando cambian deps → deactivate. Cuando eso es memoria muscular, listo.

Acceso anidado seguro: un helper pequeño

Un patrón mínimo para leer claves anidadas de dicts (p. ej. de JSON o respuestas de API) sin crashear por claves faltantes:

import json

def get_nested(data: dict, *keys, default=None):
    """Get a nested key without KeyError. Example: get_nested(d, 'user', 'address', 'city')"""
    for key in keys:
        if not isinstance(data, dict):
            return default
        data = data.get(key)
        if data is None:
            return default
    return data

with open("config.json") as f:
    config = json.load(f)

city = get_nested(config, "user", "address", "city", default="unknown")
print(f"City: {city}")

data.get(key) devuelve None o tu default si falta la clave. Encadenar eso en un loop te da acceso profundo seguro. El type hint data: dict ayuda cuando el script crece.

Súper técnico: escribir tu propio context manager

Python te da dos formas de implementar uno.

1. Basado en clases: `enter` y `exit`

Cualquier clase que defina __enter__ y __exit__ puede usarse con with:

import time

class Timer:
    """Context manager that prints how long the block took."""
    def __enter__(self):
        self.start = time.perf_counter()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        elapsed = time.perf_counter() - self.start
        print(f"Elapsed: {elapsed:.3f}s")
        return False  # don't suppress exceptions

# Usage
with Timer():
    time.sleep(0.1)
# Elapsed: 0.100s

__enter__ corre al entrar al bloque with; su return es lo que recibes tras el as (p. ej. with Timer() as t:).
__exit__ corre al salir del bloque (normal o por excepción). Los tres argumentos son el tipo, valor y traceback de la excepción; si devuelves True, Python la traga. Devolver False (o nada) la re-lanza.
Aquí solo lo usamos para medir tiempo e imprimir; no suprimimos errores.

2. Basado en generadores: `@contextmanager`

Para casos simples, un generador más contextlib.contextmanager es menos boilerplate:

from contextlib import contextmanager

@contextmanager
def temporary_override(obj, attr, value):
    """Temporarily override an attribute; restore it when leaving the block."""
    old = getattr(obj, attr, None)
    setattr(obj, attr, value)
    try:
        yield
    finally:
        if old is not None:
            setattr(obj, attr, old)
        else:
            delattr(obj, attr)

# Example: temporarily change a config
class Config:
    debug = False

with temporary_override(Config, "debug", True):
    print(Config.debug)  # True
print(Config.debug)  # False again

Todo lo anterior al yield es "setup"; todo lo posterior (en el finally) es "teardown".
El finally garantiza que el teardown corre aunque el bloque lance. Eso es lo que hace seguros a los context managers.
Este patrón aparece en todas partes: mocking en tests, cambiar env vars, adquirir y liberar locks.

Por qué merece la pena saberlo

Qué sigue

After finishing the book

What you need in the real world: virtual environments

Why venv matters

Dependencies: Project A needs requests==2.28, project B needs 2.31. One global install can’t satisfy both.
Reproducibility: pip freeze > requirements.txt and pip install -r requirements.txt so you and others can recreate the same environment.
No pollution: Your system Python stays clean; no sudo pip install or permission mess.

Quick loop

python3 -m venv .venv
source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -r requirements.txt
# ... work ...
pip freeze > requirements.txt
deactivate

Create → activate → install → freeze when deps change → deactivate. Once that’s muscle memory, you’re set.

Safe nested access: a small helper

Here’s a minimal pattern for reading nested dict keys (e.g. from JSON or API responses) without crashing on missing keys:

import json

def get_nested(data: dict, *keys, default=None):
    """Get a nested key without KeyError. Example: get_nested(d, 'user', 'address', 'city')"""
    for key in keys:
        if not isinstance(data, dict):
            return default
        data = data.get(key)
        if data is None:
            return default
    return data

with open("config.json") as f:
    config = json.load(f)

city = get_nested(config, "user", "address", "city", default="unknown")
print(f"City: {city}")

data.get(key) returns None or your default if the key is missing. Chaining that in a loop gives you safe deep access. Type hint data: dict helps when the script grows.

Super technical: writing your own context manager

Python gives you two ways to implement one.

1. Class-based: `enter` and `exit`

Any class that defines __enter__ and __exit__ can be used with with:

import time

class Timer:
    """Context manager that prints how long the block took."""
    def __enter__(self):
        self.start = time.perf_counter()
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        elapsed = time.perf_counter() - self.start
        print(f"Elapsed: {elapsed:.3f}s")
        return False  # don't suppress exceptions

# Usage
with Timer():
    time.sleep(0.1)
# Elapsed: 0.100s

__enter__ runs when you enter the with block; its return value is what you get after as (e.g. with Timer() as t:).
__exit__ runs when you leave the block (normally or by exception). The three arguments are the exception type, value, and traceback; if you return True, Python swallows the exception. Returning False (or nothing) re-raises it.
Here we only use it to measure time and print; we don’t suppress errors.

2. Generator-based: `@contextmanager`

For simple cases, a generator plus contextlib.contextmanager is less boilerplate:

from contextlib import contextmanager

@contextmanager
def temporary_override(obj, attr, value):
    """Temporarily override an attribute; restore it when leaving the block."""
    old = getattr(obj, attr, None)
    setattr(obj, attr, value)
    try:
        yield
    finally:
        if old is not None:
            setattr(obj, attr, old)
        else:
            delattr(obj, attr)

# Example: temporarily change a config
class Config:
    debug = False

with temporary_override(Config, "debug", True):
    print(Config.debug)  # True
print(Config.debug)  # False again

Everything before yield is “setup”; everything after (in the finally) is “teardown”.
The finally ensures teardown runs even if the block raises. That’s what makes context managers safe.
This pattern shows up everywhere: mocking in tests, changing env vars, acquiring and releasing locks.

Después de terminar el libro

Lo que necesitas en el mundo real: entornos virtuales

Por qué importa venv

Loop rápido

Acceso anidado seguro: un helper pequeño

Súper técnico: escribir tu propio context manager

1. Basado en clases: __enter__ y __exit__

2. Basado en generadores: @contextmanager

Por qué merece la pena saberlo

Qué sigue

After finishing the book

What you need in the real world: virtual environments

Why venv matters

Quick loop

Safe nested access: a small helper

Super technical: writing your own context manager

1. Class-based: __enter__ and __exit__

2. Generator-based: @contextmanager

Why this is worth knowing

What’s next

Después de terminar el libro

Lo que necesitas en el mundo real: entornos virtuales

Por qué importa venv

Loop rápido

Acceso anidado seguro: un helper pequeño

Súper técnico: escribir tu propio context manager

1. Basado en clases: __enter__ y __exit__

2. Basado en generadores: @contextmanager

Por qué merece la pena saberlo

Qué sigue

After finishing the book

What you need in the real world: virtual environments

Why venv matters

Quick loop

Safe nested access: a small helper

Super technical: writing your own context manager

1. Class-based: __enter__ and __exit__

2. Generator-based: @contextmanager

Why this is worth knowing

What’s next

1. Basado en clases: `enter` y `exit`

2. Basado en generadores: `@contextmanager`

1. Class-based: `enter` and `exit`

2. Generator-based: `@contextmanager`

1. Basado en clases: `enter` y `exit`

2. Basado en generadores: `@contextmanager`

1. Class-based: `enter` and `exit`

2. Generator-based: `@contextmanager`