Clases Protocol: tipado estructural para el duck typing de Python

Qué es

Una clase Protocol (PEP 544, typing.Protocol) enumera métodos y atributos; cualquier objeto que los proporcione satisface el tipo, sea o no que su clase herede del protocolo. La documentación de typing llama a esto subtipado estructural (duck typing estático), en contraste con el subtipado nominal mediante herencia. Los «one-trick ponies» de collections.abc, como Iterable y Sized, son los propios ejemplos de la biblioteca estándar. Un protocolo puede ser genérico (class Reader[T](Protocol) desde Python 3.12, Protocol[T] antes).

Por qué importa

Las funciones que aceptan «cualquier cosa con .read()» o «cualquier cosa con .close()» están por todas partes en Python. Sin protocolos, se anotan como Any (sin verificación) o como una clase concreta (quien las llama debe heredar de ella). Un protocolo permite que el consumidor declare lo que necesita en lugar de que el productor declare lo que es: el tipo vive junto al código que depende de él, las clases de terceros encajan sin modificación, y un doble de prueba solo necesita los miembros realmente usados.

Cómo aplicarlo

• Definir el protocolo en el módulo consumidor y mantenerlo mínimo: solo los miembros que el consumidor invoca, con firmas precisas y cuerpos ....
• Usar protocolos para tipos de parámetros y clases base abstractas para implementación compartida; un protocolo no lleva código, una ABC sí puede llevarlo.
• Añadir @runtime_checkable solo donde isinstance() sea realmente necesario. La documentación indica que tales comprobaciones solo verifican la presencia de los atributos indicados e ignoran sus firmas de tipo; los protocolos sin el decorador no pueden usarse con isinstance() en absoluto.
• Nombrar los protocolos por capacidad (SupportsClose, Closable), a la manera de typing.SupportsInt y similares.
• Verificar la conformidad de forma estática donde una desviación resultaría costosa. PEP 544 indica que no hace falta heredar explícitamente para la verificación de tipos, pero que hacerlo permite al verificador comprobar la clase en su propia definición y le da implementaciones por defecto. La alternativa, asignar una instancia a una variable anotada con el protocolo, también funciona; el PEP la desaconseja en código de aplicación porque se lee como código muerto y necesita una instancia, así que conviene reservarla para un módulo de pruebas.

Trampas

Los miembros de atributo (name: str) los satisfacen tanto atributos simples como propiedades, pero un verificador rechaza una propiedad de solo lectura donde se declaró un atributo asignable. Un método cuyos nombres de parámetro difieren de los del protocolo puede reportarse como incompatible, porque quien llama puede pasarlos por palabra clave; marcar los parámetros como solo posicionales (/) donde los nombres no formen parte del contrato. La documentación observa que una comprobación isinstance() contra un protocolo verificable en tiempo de ejecución puede ser sorprendentemente lenta en comparación con una comprobación de clase, y que los atributos asignados más tarde en __init__ fallan la prueba de presencia hasta que se establecen. Las clases Protocol no pueden instanciarse. Heredar explícitamente de un protocolo está permitido, pero entonces quien lea el código ve una relación nominal donde no hacía falta ninguna.