El 27 de octubre de 2026, Microsoft anunció formalmente el Type Server Protocol (TSP). Con esta reestructuración arquitectónica, Pyright —un pilar mantenido durante una década— se extrae de Pylance para convertirse en un componente intercambiable. A su vez, Pyrefly, el comprobador de tipos de código abierto desarrollado por Meta, se integra por completo como el primer backend externo.
Esta modificación introduce un canal dedicado a la semántica de tipos por encima del Language Server Protocol (LSP). Al relegar el autocompletado, la navegación y las sugerencias en línea al rol de consumidores secundarios, el protocolo eleva el sistema de tipos a un servicio independiente de consultas semánticas, orientándose especialmente a herramientas de análisis automatizado y agentes de IA.
Desacople tras diez años: Pylance se libera de la exclusividad con Pyright
En la arquitectura anterior, Pylance y Pyright formaban un bloque indivisible. Pyright recorría el árbol sintáctico y calculaba las inferencias de tipos, mientras que Pylance gestionaba la interfaz externa, encargándose del autocompletado, la navegación y el entorno en VS Code. Aunque esta unión garantizaba estabilidad de fábrica, impedía sustituir libremente el motor de análisis de tipos subyacente.
El TSP rompe esta estructura monolítica. Pylance conserva las capacidades de inteligencia de Python y la integración con GitHub Copilot, pero el diagnóstico y el cálculo de tipos se desacoplan en servicios independientes. Pyright pasa a ser el comprobador predeterminado, permitiendo que cualquier motor que cumpla la especificación TSP pueda conectarse sin fricciones.
Este desacople permite a los desarrolladores cambiar de motor sin renunciar a su ecosistema de trabajo habitual. El uso de extensiones de terceros independientes suele romper la integración con los entornos virtuales y Copilot. Al canalizar la comunicación a través de Pylance mediante TSP, el editor aprovecha nuevos motores de cálculo conservando la experiencia de usuario.
1,8 millones de líneas por segundo con Pyrefly de Meta: solución para grandes monorrepositorios
Meta se consolidó como el primer gran aliado del TSP al presentar Pyrefly, plenamente compatible con el nuevo protocolo. En pruebas de rendimiento, Pyrefly demostró una capacidad de procesamiento de 1,8 millones de líneas de código por segundo. En monorrepositorios de millones de líneas, el análisis completo se reduce de minutos a pocos segundos, eliminando congelamientos y bloqueos en el editor.
Este rendimiento proviene de la amplia experiencia de Meta manteniendo sistemas masivos en Python, como Instagram. Desde 2017, la compañía ha investigado la tipificación estática para lenguajes dinámicos a gran escala. Pyrefly no es una simple prueba de concepto; llega respaldado por rigurosas pruebas en entornos reales de producción.
Para asegurar su utilidad práctica, Meta anotó exhaustivamente las principales librerías científicas. La cobertura de tipos de NumPy roza el 90 %, y la API pública de pandas cuenta con cobertura total. Las librerías dinámicas de terceros obtienen una sólida base de inferencia estática, permitiendo deducir tipos precisos incluso en bloques de código sin anotaciones explícitas.
Instantáneas y multicanal de lectura: TSP allana el camino para la automatización
En el plano técnico, el TSP se construye sobre los cimientos del LSP, utilizando el mismo protocolo de comunicación JSON-RPC. El servidor de tipos mantiene el estado del espacio de trabajo en segundo plano, resolviendo de forma centralizada la negociación de versiones, las rutas de búsqueda y las importaciones de módulos. La especificación formal y las definiciones de interfaz en TypeScript están disponibles como código abierto en la ruta docs/tsp del repositorio microsoft/pylance-release.
La versión 0.4.1 de la especificación introduce dos diseños esenciales: resultados de tipos vinculados a instantáneas (snapshots) y canales de solo lectura multiconexión. Mientras que la interfaz gráfica del editor solo requiere diagnósticos unidireccionales, las herramientas de análisis automático necesitan leer el estado del código de manera concurrente. Esta arquitectura multicanal permite lecturas paralelas sin bloquear la interfaz de edición.
El protocolo ofrece tres consultas principales: tipos inferidos (computed), tipos declarados (declared) y tipos esperados (expected). Estas interfaces aplanan el árbol sintáctico abstracto (AST) en datos estructurados accesibles mediante llamadas RPC ligeras. Gracias a que el contexto se fragmenta en campos deterministas, los agentes automatizados pueden consultar restricciones de tipo directamente sin tener que analizar el AST por su cuenta.
Transición fluida: activación de Pyrefly en VS Code
Para los desarrolladores, la transición al nuevo backend es sumamente sencilla. Requiere la extensión Pylance en su versión 2026.4.1 o superior y Pyrefly en versión 0.60.0 o posterior. Con estos requisitos se establece la negociación del protocolo y se garantiza la estabilidad de los canales de solo lectura.
Cuando Pyrefly está instalado en el espacio de trabajo o entorno virtual, o cuando el archivo de configuración incluye [tool.pyrefly], VS Code lo detecta automáticamente y muestra un cuadro de diálogo de confirmación. Basta con aceptar para que el editor active Pyrefly como fuente de diagnósticos.
Figura 1: Al instalar Pyrefly en el entorno de trabajo, VS Code pregunta si se desea utilizar como fuente de diagnósticos de tipo. Fuente: devblogs.microsoft.com
También es posible configurarlo de forma manual. En el ajuste Python › Analysis: Diagnostics Source, se ofrecen tres alternativas: Pylance, Pylance + Pyright y Pylance + Pyrefly. Esta flexibilidad permite regresar al motor estándar en cualquier momento.
Figura 2: Configuración de Diagnostics Source en las opciones de la extensión de Python para elegir el comprobador dentro de Pylance. Fuente: devblogs.microsoft.com
Una vez realizado el cambio, la barra de estado inferior de VS Code refleja el backend activo con el texto Diagnostics Source: Pylance + Pyrefly. A partir de ese momento, Pyrefly asume el cálculo pesado de tipos, mientras que Pylance sigue gestionando de forma nativa la interfaz y los atajos del editor.
Figura 3: La barra de estado confirma el backend activo, verificando la integración fluida entre Pylance y Pyrefly. Fuente: devblogs.microsoft.com
Redefiniendo el ecosistema: el servicio de tipos como infraestructura para IA
Si el único propósito fuera resaltar errores sintácticos con líneas onduladas, Microsoft no habría necesitado rediseñar Pyright tras diez años de desarrollo. El verdadero motor de este cambio es la necesidad crítica de contexto semántico exacto que demandan los modelos de lenguaje (LLM). Las sugerencias de Copilot, el código generado mediante chat y las herramientas del Model Context Protocol (MCP) dependen de tipos semánticos precisos.
Los modelos de lenguaje no pueden resolver con certeza el despacho dinámico en sistemas complejos basándose únicamente en coincidencias de texto. El servidor de tipos calcula previamente el grafo de dependencias de símbolos y lo expone mediante APIs de instantáneas. De este modo, los agentes de código realizan consultas estructuradas sobre parámetros y tipos, reduciendo significativamente los errores en el código generado.
Con este protocolo abierto, Microsoft asegura una posición estratégica en el ecosistema. Quien define el estándar de consultas de tipos establece la interfaz semántica entre los agentes inteligentes y las bases de código. La transformación del análisis de tipos en un servicio autónomo redefine los cimientos de la cadena de herramientas de desarrollo asistido por IA.
Enlaces de referencia:
- Anuncio oficial en el blog de Python de Microsoft
- Documentación técnica y benchmarks oficiales de Pyrefly
