Microsoft lanza TSP, protocolo de tipos para Python

Qué es el Type Server Protocol y por qué Microsoft lo desacopla del editor

El Type Server Protocol (TSP) es un protocolo JSON-RPC que permite a un cliente pedirle a un type server los datos de análisis de tipos de un workspace de Python. Microsoft publicó su especificación en el repositorio de Pylance y la alineó con la versión Pylance 2026.4.1.

La decisión de fondo es arquitectónica: TSP reutiliza las formas de datos del Language Server Protocol (LSP) —posiciones, rangos y URIs representadas como strings— pero mueve las consultas de tipos a un canal propio, con el prefijo typeServer/. En la práctica, el editor deja de ser el único que puede preguntar qué tipo tiene una variable.

El ecosistema donde aterriza esto es enorme. El stack de Python de Microsoft —las extensiones Python, Pylance y Jupyter— es el más popular del marketplace de VS Code, con más de 421 millones de instalaciones combinadas, según ADTmag. Cualquier cambio en cómo se expone el análisis de tipos toca a una base de desarrolladores difícil de igualar.

¿Qué consultas resuelve TSP y cómo se diferencia del LSP?

TSP define un conjunto deliberadamente pequeño de mensajes. Los tres centrales son consultas de tipo sobre un nodo o una declaración:

• typeServer/getComputedType devuelve el tipo inferido por el flujo del código. Si a se estrecha a int, el tipo computado de b en b = a + 1 es int.
• typeServer/getDeclaredType devuelve el tipo escrito explícitamente en el código. Para def foo(a: int | str), el tipo declarado de a es int | str.
• typeServer/getExpectedType devuelve el tipo que el contexto espera. En la llamada foo(4), el tipo esperado del argumento es int | str.

A eso se suman typeServer/getPythonSearchPaths, typeServer/resolveImport, typeServer/getSnapshot y typeServer/getSupportedProtocolVersion. La diferencia con LSP es de especialización: LSP resuelve cómo un editor habla con cualquier language server; TSP resuelve cómo cualquier cliente pregunta por tipos de Python con una semántica precisa.

Cómo funciona el versionado y los snapshots

TSP usa strings de versión semántica para verificar compatibilidad entre cliente y servidor. Mientras el protocolo siga en la línea 0.x, los cambios de versión menor pueden ser incompatibles; los cambios de parche se mantienen retrocompatibles dentro de la misma línea menor. El historial documentado va de 0.1.0 (versión inicial) a 0.4.1, que agregó la negociación multi-conexión.

El otro concepto central es el snapshot: un entero no negativo que identifica una vista del estado de análisis en un punto del tiempo. Los handles de tipo, las declaraciones y los símbolos solo son válidos para el snapshot en el que se devolvieron. El servidor debe avanzar el snapshot cuando un resultado previo puede quedar inválido: cambios en archivos abiertos o cerrados, cambios de configuración, archivos vigilados o dependencias.

Si un cliente manda un snapshot viejo, la respuesta esperada es un error JSON-RPC retryable —Microsoft recomienda ServerCancelled (-32802)— para que el cliente pida un snapshot fresco y reintente. Es un patrón que cualquier equipo que construya cachés reconoce: invalidación explícita en lugar de resultados silenciosamente obsoletos.

¿Qué agrega el modo multi-conexión?

La versión 0.4.1 introdujo el modo multi-conexión, una función de rendimiento opcional. Permite abrir canales adicionales al mismo type server para consultas de solo lectura, mientras la conexión principal conserva el estado mutable del workspace.

La negociación ocurre en el initialize normal de LSP: ambas partes anuncian capabilities.experimental.typeServerMultiConnection con una lista de supportedTransports. Hoy el único transporte incorporado soportado es ipc. El modo se activa solo si ambos lados lo anuncian y comparten al menos un transporte.

Las reglas son estrictas. La conexión principal es dueña de la inicialización, el ciclo de vida, la sincronización de documentos, las notificaciones que cambian estado y el control de conexión (typeServer/connection). Las conexiones extra son exclusivamente TSP y de solo lectura. Un servidor debe seguir funcionando correctamente en modo de una sola conexión: el soporte multi-conexión no puede ser un requisito para la corrección del protocolo.

Qué significa esto para tu startup

Si construyes herramientas para desarrolladores, TSP abre una puerta concreta: puedes consultar el análisis de tipos de Python sin depender de que el usuario esté dentro de VS Code. Eso habilita productos que antes requerían reimplementar un type checker o acoplarse a un editor específico.

• Evalúa TSP si tu producto analiza código Python. Un linter, un asistente de refactorización o un agente que revisa pull requests puede pedir tipos computados, declarados y esperados a un type server en lugar de parsear el AST por su cuenta. Empieza por typeServer/getSupportedProtocolVersion y verifica compatibilidad antes de asumir nada.
• Diseña para snapshots desde el primer día. Si tu herramienta cachea resultados de tipos, trátalos como válidos solo para el snapshot que los produjo. Manejar el error -32802 con un reintento limpio es más barato que depurar resultados obsoletos en producción.
• No adoptes multi-conexión sin necesidad. Es una optimización para cargas de solo lectura de alto volumen. Si tu volumen es bajo, el modo de una sola conexión es más simple y el protocolo garantiza que es suficiente.

¿Vale la pena adoptar TSP hoy?

Hay una advertencia importante: el protocolo está en la línea 0.x, y Microsoft advierte que los cambios de versión menor pueden ser incompatibles. Adoptarlo hoy significa asumir mantenimiento de compatibilidad, no una API congelada.

También conviene mirar el contexto. Microsoft viene invirtiendo en separar responsabilidades dentro de su stack de Python: en agosto de 2025 movió la gestión de entornos a una extensión propia, Python Environments, que pasó de 486 instalaciones en su preview de enero a casi 1,7 millones de descargas, según ADTmag. TSP sigue la misma lógica: cada pieza hace una cosa y expone una interfaz clara.

Para un equipo pequeño, la lectura práctica es que el análisis de tipos de Python se está volviendo un servicio consumible, no una función atada a un editor. Eso reduce el costo de construir herramientas de código, y en un mercado donde el tooling para desarrolladores compite por atención, ese ahorro es ventaja.

Conclusión

El Type Server Protocol no es un producto que un founder vaya a comprar, pero sí una pieza de infraestructura que puede ahorrar meses de trabajo. Microsoft está estandarizando cómo se pregunta por tipos en Python, y lo está haciendo sobre las convenciones de LSP que el ecosistema ya conoce.

Si tu roadmap incluye análisis de código Python, vale la pena leer los artefactos del protocolo —typeServerProtocol.ts, tsp.json y tsp.schema.json— antes de decidir si construyes o integras. La ventana para posicionarse temprano sobre un protocolo en 0.x suele cerrarse rápido.

Fuentes

• Type Server Protocol (Pylance docs) (fuente original)
• Microsoft's Python Environment Tool Finally Tackles Developers' Biggest Headache (ADTmag)
• Programming language Python: Microsoft's VS Code gets Pylance (ZDNet)
• Pylance introduced to improve Python experience in VS Code (SD Times)