Escribí un intérprete de Python en Python. Lo que aprendí no tiene nada que ver con Python

150 puntos en Hacker News. Ese número me detuvo el scroll a las 11pm un martes. El título era simple: "Writing a Python interpreter in Python". Lo abrí pensando que iba a ser otro tutorial de juguete. Cerré la laptop a las 2am habiendo escrito un lexer, un parser, y un evaluador funcional — y con una pregunta que no me esperaba: ¿por qué ahora entiendo mejor cuándo me está mintiendo Claude?

Eso es lo que te cuento hoy.

Intérprete Python en Python: el punto de entrada

El post original es sólido. La idea central es que Python es lo suficientemente expresivo para modelar sus propias estructuras de evaluación. Podés representar un AST con dataclasses, recorrerlo con pattern matching, y tener un loop REPL funcional en menos de 500 líneas. No es CPython. No maneja todos los edge cases. Pero funciona, y eso es exactamente el punto.

Empecé siguiendo el post línea por línea. Después empecé a divergir. Y en la divergencia está lo interesante.

# Paso 1: El Lexer — convierte texto en tokens
from dataclasses import dataclass
from enum import Enum, auto
from typing import Iterator

class TipoToken(Enum):
    NUMERO = auto()
    CADENA = auto()
    NOMBRE = auto()      # variables, funciones
    MAS = auto()
    MENOS = auto()
    MULT = auto()
    DIV = auto()
    IGUAL = auto()       # =
    IGUAL_IGUAL = auto() # ==
    LPAREN = auto()
    RPAREN = auto()
    DEF = auto()
    RETURN = auto()
    IF = auto()
    ELSE = auto()
    NEWLINE = auto()
    EOF = auto()

@dataclass
class Token:
    tipo: TipoToken
    valor: str | int | float | None
    linea: int

def lexer(codigo: str) -> Iterator[Token]:
    """Convierte string de código en stream de tokens"""
    palabras_clave = {
        'def': TipoToken.DEF,
        'return': TipoToken.RETURN,
        'if': TipoToken.IF,
        'else': TipoToken.ELSE,
    }
    i = 0
    linea = 1
    
    while i < len(codigo):
        c = codigo[i]
        
        # Ignorar espacios
        if c == ' ':
            i += 1
            continue
            
        # Contar saltos de línea
        if c == '\n':
            yield Token(TipoToken.NEWLINE, None, linea)
            linea += 1
            i += 1
            continue
        
        # Números
        if c.isdigit():
            inicio = i
            while i < len(codigo) and (codigo[i].isdigit() or codigo[i] == '.'):
                i += 1
            valor = codigo[inicio:i]
            yield Token(
                TipoToken.NUMERO, 
                float(valor) if '.' in valor else int(valor),
                linea
            )
            continue
        
        # Identificadores y palabras clave
        if c.isalpha() or c == '_':
            inicio = i
            while i < len(codigo) and (codigo[i].isalnum() or codigo[i] == '_'):
                i += 1
            texto = codigo[inicio:i]
            tipo = palabras_clave.get(texto, TipoToken.NOMBRE)
            yield Token(tipo, texto, linea)
            continue
        
        # Operadores
        if c == '=' and i + 1 < len(codigo) and codigo[i+1] == '=':
            yield Token(TipoToken.IGUAL_IGUAL, '==', linea)
            i += 2
            continue
            
        operadores = {
            '+': TipoToken.MAS, '-': TipoToken.MENOS,
            '*': TipoToken.MULT, '/': TipoToken.DIV,
            '=': TipoToken.IGUAL, '(': TipoToken.LPAREN,
            ')': TipoToken.RPAREN,
        }
        if c in operadores:
            yield Token(operadores[c], c, linea)
            i += 1
            continue
            
        i += 1  # ignorar caracteres desconocidos por ahora
    
    yield Token(TipoToken.EOF, None, linea)

Esto es el lexer. La parte que la mayoría de los tutoriales se saltea o abstracta con re. Acá lo escribí a mano porque quería sentir cada decisión.

# Paso 2: El AST — la estructura que representa el programa
@dataclass
class Nodo:
    pass

@dataclass
class NumeroNodo(Nodo):
    valor: int | float

@dataclass
class NombreNodo(Nodo):
    nombre: str

@dataclass
class BinOpNodo(Nodo):
    izq: Nodo
    op: str
    der: Nodo

@dataclass
class AsignacionNodo(Nodo):
    nombre: str
    valor: Nodo

@dataclass
class FuncDefNodo(Nodo):
    nombre: str
    params: list[str]
    cuerpo: list[Nodo]

@dataclass
class LlamadaNodo(Nodo):
    func: str
    args: list[Nodo]

@dataclass
class ReturnNodo(Nodo):
    valor: Nodo

# Paso 3: El Evaluador — donde pasan las cosas de verdad
class EntornoEjecucion:
    """Scope: variables locales + acceso al scope padre"""
    def __init__(self, padre=None):
        self.variables = {}
        self.padre = padre
    
    def obtener(self, nombre: str):
        if nombre in self.variables:
            return self.variables[nombre]
        if self.padre:
            return self.padre.obtener(nombre)
        raise NameError(f"Nombre '{nombre}' no definido")
    
    def asignar(self, nombre: str, valor):
        self.variables[nombre] = valor

def evaluar(nodo: Nodo, entorno: EntornoEjecucion):
    """Recorre el AST y ejecuta cada nodo"""
    match nodo:
        case NumeroNodo(valor):
            return valor
            
        case NombreNodo(nombre):
            return entorno.obtener(nombre)
            
        case BinOpNodo(izq, op, der):
            # Evaluación lazy — primero los operandos
            v_izq = evaluar(izq, entorno)
            v_der = evaluar(der, entorno)
            match op:
                case '+': return v_izq + v_der
                case '-': return v_izq - v_der
                case '*': return v_izq * v_der
                case '/': return v_izq / v_der
                case '==': return v_izq == v_der
                
        case AsignacionNodo(nombre, valor):
            resultado = evaluar(valor, entorno)
            entorno.asignar(nombre, resultado)
            return resultado
            
        case FuncDefNodo(nombre, params, cuerpo):
            # Guardar la función como dato — closures simples
            entorno.asignar(nombre, (params, cuerpo, entorno))
            return None
            
        case LlamadaNodo(func, args):
            params, cuerpo, entorno_def = entorno.obtener(func)
            # Crear scope nuevo para la función
            entorno_local = EntornoEjecucion(padre=entorno_def)
            for param, arg in zip(params, args):
                entorno_local.asignar(param, evaluar(arg, entorno))
            resultado = None
            for stmt in cuerpo:
                resultado = evaluar(stmt, entorno_local)
            return resultado
            
        case ReturnNodo(valor):
            return evaluar(valor, entorno)

Tres archivos. ~300 líneas. Funciona lo suficiente para evaluar funciones simples con recursión.

Lo que aprendí sobre los LLMs cuando construís desde abajo

Acá está la parte rara. Y es el motivo real por el que estoy escribiendo esto.

Cuando terminé el evaluador básico, le pedí a Claude que me ayudara a agregar soporte para closures correctas — el caso donde una función interna captura variables del scope externo. La respuesta fue inmediata, confiada, y parcialmente incorrecta.

No era un error obvio. Era un error sutil: confundía el entorno de definición con el entorno de ejecución. En un lenguaje con evaluación dinámica de scopes (como Bash, o Emacs Lisp pre-lexical), esa respuesta hubiera sido correcta. Para Python, que tiene scoping léxico, era wrong.

Y lo vi inmediatamente. Porque acababa de escribir entorno_def a mano. Sabía exactamente qué significaba capturar ese entorno en FuncDefNodo.

Antes de este ejercicio, ¿lo hubiera visto? Probable que no. Hubiera pegado el código, corrido los tests si es que los tenía, y seguido.

Esto me conecta con algo que mencioné en el post sobre cuántos tokens gasto por tarea real: el costo no es solo económico. Es cognitivo. Cada vez que delegás sin entender la capa de abajo, estás pagando con capacidad de detección de errores.

El LLM no te miente con mala intención. Te da la respuesta más probable dado el contexto. Si el contexto más frecuente en su training data era evaluación dinámica de scopes, eso es lo que vas a recibir. La capa de abstracción hace que no lo notes.

También lo vi con CodeBurn desde otro ángulo: cuando sabés exactamente qué tiene que hacer el código, tus prompts son mejores, tus correcciones son más rápidas, y el loop de iteración se acorta. No porque el modelo sea mejor — porque vos sos mejor interlocutor.

Los errores que cometí (y lo que enseñan)

Error 1: Confundir el parser con el evaluador.

Empecé a poner lógica de evaluación en el parser. "Es más fácil hacer la suma acá mientras parseo el +". Técnicamente funcional, arquitectónicamente un desastre. Dos horas después entendí por qué existe la separación. No por dogma — porque cuando querés hacer análisis estático, optimizaciones, o simplemente debuggear, necesitás el AST limpio.

El LLM nunca me hubiera dado ese error. Me hubiera dado código separado desde el principio. Y yo no hubiera aprendido por qué está separado.

Error 2: Querer manejar errores antes de tener funcionalidad.

A mitad del lexer quise agregar mensajes de error prolijos con número de línea, columna, y contexto. Tres horas después tenía un sistema de errores hermoso para un lexer que no funcionaba todavía. El clásico.

Error 3: No tener un test case mínimo desde el principio.

Empecé a escribir sin saber qué quería que funcionara primero. La solución fue simple:

# El test mínimo que debería funcionar desde el día 1
CODIGO_TEST = """
def suma(a, b):
    return a + b

resultado = suma(3, 4)
"""

# Si esto funciona, el intérprete existe.
# Todo lo demás es feature.

Tener ese contrato claro desde el principio te organiza todo lo demás. Es lo que en el mundo de los agentes llamamos "verificación" — el mismo principio que exploré con SPICE y Claude Code: no alcanza con que el agente genere algo, tiene que haber una capa de verificación externa.

FAQ: Intérprete de Python en Python

¿Cuál es la diferencia entre un intérprete y un compilador?

Un compilador traduce el código fuente a otra representación (bytecode, código máquina) antes de ejecutarlo. Un intérprete lo ejecuta directamente, generalmente recorriendo el AST o evaluando representaciones intermedias. CPython es técnicamente un intérprete de bytecode: primero compila a .pyc, después ejecuta ese bytecode en una máquina virtual. Lo que construí acá es más simple: evalúa el AST directamente, sin paso intermedio.

¿Esto tiene alguna aplicación práctica o es solo un ejercicio?

Más práctica de lo que parece. Los DSLs (Domain Specific Languages) que aparecen en configuración de infraestructura, reglas de negocio, o sistemas de templates usan exactamente esta arquitectura. Si alguna vez trabajaste con expresiones en JINJA2, reglas en Drools, o filtros en Elasticsearch — estabas usando algo construido con estas mismas ideas.

¿Por qué escribir el lexer a mano en vez de usar re?

Por el mismo motivo por el que aprendés a multiplicar antes de usar calculadora. El objetivo no era tener un lexer de producción. Era entender qué decisiones toma un lexer. Las librerías como PLY o lark hacen esto mejor y más rápido — pero si no entendés qué están haciendo, tampoco vas a entender los mensajes de error cuando fallen.

¿Qué tiene que ver esto con usar LLMs para programar?

Todo. El LLM genera código que es estadísticamente plausible dado el contexto. Si vos no entendés la semántica de lo que pediste, no podés verificar si lo que recibiste es correcto. No es que los LLMs sean malos — es que la verificación requiere comprensión. Cuanto más bajo bajaste en las abstracciones, más fácil es detectar cuándo el output tiene sentido y cuándo no. Lo escribo con más detalle en el post sobre el costo real por tarea en Claude Code.

¿Hace falta saber teoría de compiladores para esto?

No. El post original de HN no asume conocimiento previo de compiladores, y yo tampoco lo tenía cuando arranqué Ciencias de la Computación. Materias de Autómatas y Compiladores las hice después — y cuando las hice, entendí retrospectivamente por qué las cosas funcionaban como funcionaban. Podés empezar con el código y la teoría viene sola si la curiosidad está.

¿Cuánto tiempo lleva construir algo así desde cero?

El intérprete mínimo funcional (lexer + parser recursivo descendente + evaluador con funciones) me llevó un fin de semana — con interrupciones, cafés, y un par de callejones sin salida. Si seguís el post de referencia en orden, probablemente menos. El tiempo real de aprendizaje no es el de escritura: es el de los momentos donde algo no funciona y tenés que entender por qué.

Lo que me llevé, en serio

Construir capas de abstracción desde abajo no te hace más rápido. Te hace más preciso.

En un contexto donde los modelos frontier son cada vez más caros y los agentes corren en infraestructura distribuida, la capacidad de verificar el output de la IA no es un nice-to-have. Es la diferencia entre usar una herramienta y ser usado por una herramienta.

Aprobé Análisis II en el cuarto intento. No porque sea malo en matemática — porque en los primeros tres intentos estaba siguiendo pasos sin entender estructuras. El cuarto intento lo aprobé cuando dejé de memorizar y empecé a construir intuición desde definiciones.

El intérprete me enseñó lo mismo, pero sobre código y sobre IA.

Si querés el repo completo con el código de este post, mandame un mensaje. Y si vos también construiste algo así y llegaste a conclusiones distintas — especialmente si pensás que me equivoco en la parte del LLM — me interesa la discusión.

Esa conversación es la que vale.