Comparación del verificador de tipos de Python: inferencia de contenedor vacío

Por qué los contenedores vacíos rompen las fichas tipo Python y qué se puede hacer al respecto

El sistema de escritura gradual de Python ha madurado significativamente desde que PEP 484 introdujo sugerencias de escritura en 2015. Hoy en día, millones de desarrolladores confían en verificadores de escritura estáticos para detectar errores antes de que lleguen a producción. Pero hay un rincón sutil y frustrante del sistema de tipos que todavía hace tropezar incluso a los ingenieros experimentados: ¿qué tipo tiene un contenedor vacío? Cuando escribes x = [] sin anotaciones, tu verificador de tipos tiene que adivinar, y diferentes verificadores adivinan de manera diferente. Esta divergencia crea problemas reales para los equipos que mantienen grandes bases de código, donde cambiar o combinar verificadores de tipos puede generar cientos de errores inesperados de la noche a la mañana.

Este artículo analiza cómo los cuatro principales verificadores de tipos de Python (mypy, pyright, pytype y pyre) manejan la inferencia de contenedores vacíos, por qué no están de acuerdo y qué estrategias prácticas puede adoptar para escribir Python con seguridad de tipos independientemente de su elección de herramientas.

El problema central: los contenedores vacíos son inherentemente ambiguos

Considere esta inofensiva línea de Python: resultados = []. ¿Los resultados son una lista [int]? ¿Una lista [cadena]? ¿Una lista[dict[str, Any]]? Sin contexto adicional, realmente no hay forma de saberlo. Al tiempo de ejecución de Python no le importa (las listas son heterogéneas por naturaleza), pero los verificadores de tipos estáticos necesitan asignar un tipo concreto a cada variable para hacer su trabajo. Esto crea una tensión fundamental entre la flexibilidad dinámica de Python y las garantías que el análisis estático intenta ofrecer.

El problema se agrava con los diccionarios y conjuntos. Un {} vacío en realidad se analiza como un dict, no como un conjunto, lo que agrega ambigüedad sintáctica además de la ambigüedad a nivel de tipo. Y los contenedores anidados (piense en defaultdict(list) o results = {k: [] for k inkeys}) llevan los motores de inferencia al límite. Cada verificador de tipo ha desarrollado su propia heurística y las diferencias son más significativas de lo que la mayoría de los desarrolladores creen.

En los sistemas de producción que procesan cargas de trabajo reales, ya sea un CRM que maneja registros de clientes, un módulo de facturación que genera líneas de pedido o un canal de análisis que agrega métricas, los contenedores vacíos aparecen constantemente como patrones de inicialización. Equivocarse en sus tipos no sólo produce advertencias de linter; puede enmascarar errores genuinos que pasan al tiempo de ejecución.

Mypy: Inferencia diferida con Any implícito

Mypy, el verificador de tipos de Python más antiguo y ampliamente adoptado, adopta un enfoque relativamente indulgente con los contenedores vacíos. Cuando encuentra x = [] en el alcance de la función, intenta diferir la decisión de tipo e inferir el tipo de elemento a partir del uso posterior. Si escribe x = [] seguido de x.append(42), mypy inferirá lista[int]. Esta estrategia de "unión" funciona sorprendentemente bien en casos sencillos en los que el contenedor se completa dentro del mismo ámbito.

Sin embargo, el comportamiento de mypy cambia drásticamente según el contexto y la configuración de rigor. En el alcance del módulo (código de nivel superior), o cuando el contenedor se pasa a otra función antes de completarse, mypy a menudo vuelve a la lista [Cualquiera]. Bajo el indicador --strict, esto genera un error, pero en el modo predeterminado pasa silenciosamente. Esto significa que los equipos que ejecutan mypy sin modo estricto pueden acumular docenas de contenedores tipificados implícitamente que actúan como trampillas de escape del sistema de tipos, frustrando su propósito.

Un comportamiento particularmente sutil: las versiones mypy anteriores a 0.990 a veces inferían la lista[Desconocido] internamente y luego se ampliaban para listar[Cualquiera] en la asignación. Después de 0.990, la inferencia se hizo más estricta, pero el cambio rompió una sorprendente cantidad de bases de código del mundo real que habían estado confiando en el comportamiento permisivo sin darse cuenta. Este es un tema recurrente: los cambios en la inferencia de contenedores vacíos se encuentran entre las actualizaciones del verificador de tipos más disruptivas porque los patrones son muy ubicuos.

Pyright: inferencia estricta y el tipo "desconocido"

Pyright, desarrollado por Microsoft e impulsando Pylance en VS Code, adopta una postura filosófica fundamentalmente diferente. En lugar de en silencio