Respuesta

Historia del tema: Las anotaciones de tipos aparecieron en Python 3.5 (PEP 484) para soportar el análisis estático de código, la autocompleción, la refactorización y la auto-documentación. Antes, Python se las arreglaba sin tipificación estricta, pero con el crecimiento de proyectos y equipos, se volvieron necesarias para mejorar la calidad del código.

Problema: Las anotaciones de tipos son solo sugerencias para los desarrolladores y herramientas externas (mypy, Pyright, etc.), el intérprete las ignora durante la ejecución. A menudo ocurren errores si:

• Las anotaciones son incorrectas o no coinciden con los tipos reales
• Las anotaciones se rompen al cambiar dinámicamente los tipos
• Errores en estructuras complejas con Generics (por ejemplo, List[Dict[str, int]])

Solución: Utiliza anotaciones de tipos para funciones y variables para mejorar la legibilidad, el análisis del código por linters e IDEs. No hay que confiar únicamente en las anotaciones: se necesita un verificador de tipo estático. Ejemplo:

def greeting(name: str) -> str:
    return f"Hello, {name}"

def sum_nums(nums: list[int]) -> int:
    return sum(nums)

Ejemplos más complejos utilizan el módulo typing:

from typing import List, Dict, Optional

def process(data: List[Dict[str, Optional[int]]]) -> None:
    ...

Características clave:

• Las anotaciones no afectan el comportamiento del código en tiempo de ejecución
• Siempre combina los type hints con un analizador externo
• Para estructuras complejas, utiliza typing.

Preguntas capciosas.

¿El intérprete de Python maneja los tipos de las anotaciones en tiempo de ejecución?

No. Las anotaciones están disponibles a través de __annotations__, pero no controlan el comportamiento durante la ejecución.

¿Se pueden usar variables sin anotaciones en funciones anotadas?

Sí. Las anotaciones no son obligatorias, pero su ausencia puede causar confusión.

¿Se puede redefinir el tipo de una variable después de la anotación?

Sí, pero esto viola la esencia del análisis estático y puede confundir a los linters. Es mejor evitar esto:

x: int = 5
x = 'cadena'  # El linter se quejará, pero el código se ejecutará.

Errores típicos y anti-patrones

• Incongruencia entre el tipo implementado y el valor de la anotación
• No utilizar un analizador externo (linters, mypy)
• Type hints demasiado complejos o excesivos que dificultan la lectura

Ejemplo de la vida real

Caso negativo: Se anota una función, pero realmente se devuelve un tipo diferente al que está en la anotación, debido a un cambio en la lógica de la función. Pros:

• El código se ejecuta Contras:
• Fácil de obtener un bug que es difícil de probar y detectar

Caso positivo: Todas las funciones y datos están anotados, el proyecto es revisado por mypy en CI/CD. Pros:

• Alta mantenibilidad y legibilidad del código Contras:
• Requiere tiempo para implementar y formar al equipo