01 - Arquitectura de Runtime: CPython vs V8

1. CPython: El Intérprete por Defecto

Como Senior de Node.js, tu mental model está construido sobre V8: un engine JIT que compila JavaScript a código máquina optimizado en tiempo de ejecución. CPython es fundamentalmente diferente—es un intérprete de bytecode con un compilador ahead-of-time (AOT) que genera .pyc.

El Pipeline de Ejecución

[Código Fuente .py] → [AST] → [Bytecode .pyc] → [Python Virtual Machine (PVM)]

Puedes inspeccionar el bytecode generado:

import dis

def calculate_tax(amount: float, rate: float = 0.21) -> float:
    return amount * (1 + rate)

dis.dis(calculate_tax)
# Output:
#   LOAD_FAST    0 (amount)
#   LOAD_CONST   1 (1)
#   LOAD_FAST    1 (rate)
#   BINARY_OP    0 (+)
#   BINARY_OP    5 (*)
#   RETURN_VALUE

Implicación Senior: A diferencia de V8, no hay “hot path optimization” automática. El bytecode se ejecuta instrucción por instrucción. Las optimizaciones vienen de:

• Librerías escritas en C/Rust (NumPy, Pydantic V2, orjson)
• El uso correcto de estructuras de datos
• Evitar patrones que el intérprete no puede optimizar

V8 vs CPython: Trade-offs Reales

Para tu perfil: FastAPI/Uvicorn compensan el “overhead” de CPython delegando el I/O a código nativo (libuv underneath) y usando Pydantic V2 (Rust) para serialización. En benchmarks reales de API REST, la diferencia es marginal.

2. El GIL: El Elefante en la Habitación

El Global Interpreter Lock es un mutex que protege el acceso a objetos Python. Solo un thread puede ejecutar bytecode a la vez.

Por qué existe (y no es tan malo)

# Sin GIL, este código causaría race conditions:
import threading

counter = 0

def increment():
    global counter
    for _ in range(1_000_000):
        counter += 1  # READ → MODIFY → WRITE (no atómico)

# Con GIL, Python serializa las operaciones de bytecode
# Pero aún así NO es thread-safe para operaciones compuestas

El GIL y tu código async

Buena noticia para Seniors de Node: En código I/O-bound (APIs, bases de datos), el GIL se libera durante las operaciones de I/O. Esto significa que asyncio puede manejar miles de conexiones concurrentes igual que Node.js.

async def fetch_users():
    # GIL se LIBERA durante await (I/O)
    users = await db.fetch_all("SELECT * FROM users")
    # GIL se ADQUIERE para procesar el resultado
    return [User(**u) for u in users]

Cuando el GIL sí importa: CPU-bound

// Node.js: Worker Threads para CPU-bound
const { Worker } = require('worker_threads');

// Cada worker tiene su propio V8 isolate
new Worker('./heavy-computation.js');

# Python: Multiprocessing para CPU-bound
from concurrent.futures import ProcessPoolExecutor

# Cada proceso tiene su propio intérprete (y GIL)
with ProcessPoolExecutor(max_workers=4) as pool:
  results = pool.map(heavy_computation, data_chunks)

Regla Senior:

• I/O-bound → asyncio (como Node.js)
• CPU-bound → multiprocessing o delegar a C/Rust
• Mixed → run_in_executor con ProcessPoolExecutor

3. Gestión de Memoria: Reference Counting vs Generational GC

El modelo de V8 (Generational GC)

V8 divide el heap en generaciones (Young/Old) y ejecuta ciclos de GC que pueden causar stop-the-world pauses de 1-10ms.

El modelo de CPython (Reference Counting + Cycle Detector)

Python destruye objetos inmediatamente cuando su reference count llega a 0:

def process_data():
    huge_list = [x for x in range(10_000_000)]  # refcount = 1
    result = sum(huge_list)
    return result
    # huge_list sale del scope → refcount = 0 → LIBERACIÓN INMEDIATA

Ventaja: Liberación determinista de memoria. No hay “GC pauses” impredecibles.

Desventaja: No detecta ciclos automáticamente:

# Ciclo de referencias - el refcount nunca llega a 0
class Node:
    def __init__(self):
        self.parent = None
        self.children = []

parent = Node()
child = Node()
parent.children.append(child)
child.parent = parent  # ¡CICLO!

del parent, child  # Memoria NO liberada inmediatamente
# El Cycle Detector (generational GC secundario) lo limpiará eventualmente

Optimización Senior: __slots__

Por defecto, cada instancia de clase tiene un __dict__ (un diccionario completo). Para objetos con atributos fijos, __slots__ reduce el memory footprint ~40%:

# Sin __slots__: ~152 bytes por instancia
class UserBad:
    def __init__(self, id: int, email: str):
        self.id = id
        self.email = email

# Con __slots__: ~88 bytes por instancia
class UserGood:
    __slots__ = ('id', 'email')
    
    def __init__(self, id: int, email: str):
        self.id = id
        self.email = email

# Pydantic V2 usa __slots__ internamente

4. El Peligro de los Objetos Mutables como Default

Este es el error más común de developers de JS/TS migrando a Python:

// JavaScript: Nuevo array en cada llamada
function addItem(item, list = []) {
list.push(item);
return list;
}

addItem(1);  // [1]
addItem(2);  // [2] ← Nuevo array
addItem(3);  // [3] ← Nuevo array

# Python: MISMA lista compartida entre llamadas
def add_item(item, list_=[]):
  list_.append(item)
  return list_

add_item(1)  # [1]
add_item(2)  # [1, 2] ← ¡MISMO objeto!
add_item(3)  # [1, 2, 3] ← ¡MISMO objeto!

El porqué técnico

En Python, los default arguments se evalúan UNA sola vez cuando la función se define (no en cada llamada). El objeto [] se crea durante la compilación y se reutiliza.

Patrón Senior correcto

from typing import Optional

def add_item(item: int, list_: Optional[list[int]] = None) -> list[int]:
    if list_ is None:
        list_ = []
    list_.append(item)
    return list_

# O más idiomático con walrus operator (Python 3.8+):
def add_item(item: int, list_: list[int] | None = None) -> list[int]:
    (list_ := list_ or []).append(item)
    return list_

5. Scoping: LEGB y el keyword nonlocal

Python usa la regla LEGB (Local → Enclosing → Global → Built-in):

// JavaScript: Closures con let/const son transparentes
function createCounter() {
let count = 0;
return () => {
  count += 1;  // Modifica la variable del scope padre
  return count;
};
}

const counter = createCounter();
counter();  // 1
counter();  // 2

# Python: Requiere 'nonlocal' para modificar
def create_counter():
  count = 0
  
  def increment():
      nonlocal count  # ¡OBLIGATORIO para reasignar!
      count += 1
      return count
  
  return increment

counter = create_counter()
counter()  # 1
counter()  # 2

Sin nonlocal, Python crea una variable local nueva en lugar de modificar la del scope padre.

6. Interoperabilidad con C: El Secreto del Performance

La razón por la que el ecosistema Python es tan potente para data science y ML no es Python en sí—son las extensiones en C/C++/Rust.

El patrón “Python como pegamento”

import numpy as np  # Core en C/Fortran
import orjson       # JSON parsing en Rust
from pydantic import BaseModel  # Validación en Rust (V2)

# Tu código Python orquesta, las librerías nativas ejecutan
data = orjson.loads(huge_json_bytes)  # 10x más rápido que json.loads
matrix = np.array(data["values"])      # Operaciones vectorizadas en C

Cuándo escribir extensiones nativas

Para un Senior, raramente necesitas escribir C. Las opciones modernas:

• Cython: Python con tipos → compila a C
• PyO3/Maturin: Extensiones en Rust (como Pydantic V2)
• Numba: JIT para código numérico

7. La Tabla Rosetta: Node.js → Python

Conclusión

La transición de Node.js a Python no es sobre “aprender nueva sintaxis”—es sobre cambiar tu mental model:

1. No esperes JIT magic: Optimiza eligiendo las estructuras de datos correctas y delegando a librerías nativas.
2. El GIL no es tu enemigo: Para APIs I/O-bound, asyncio es tan eficiente como el Event Loop.
3. La memoria es predecible: Reference counting te da control determinista.
4. Python favorece la explicitud: Si algo parece “mágico”, probablemente hay un keyword explícito (nonlocal, global, yield).

En el siguiente capítulo, configuraremos el entorno de desarrollo con uv, el gestor de dependencias que está reemplazando a pip/poetry.