¿Cómo utilizar consejos tipo en Python 3.6?

Noté que Python 3.5 y Python 3.6 agregaron muchas características sobre la comprobación de tipos estáticos, así que probé con el siguiente código (en Python 3.6, versión estable).

from typing import List a: List[str] = [] a.append('a') a.append(1) print(a) 

Lo que me sorprendió fue que python no me dio un error ni una advertencia, aunque se adjuntó a una list que solo debería contener cadenas. Pycharm detectó el error de tipo y me dio una advertencia al respecto, pero no era obvio y no se mostraba en la consola de salida; temía que a veces lo echara de menos. Me gustaría los siguientes efectos:

  1. Si es obvio que usé el tipo incorrecto tal como se muestra arriba, arroje una advertencia o error.
  2. Si el comstackdor no pudo verificar de manera confiable si el tipo que usé era correcto o incorrecto, ignórelo.

¿Es eso posible? Tal vez mypy podría hacerlo, pero preferiría usar la comprobación de tipos del estilo python-3.6 (como a: List[str] ) en lugar del estilo de comentario (como # type List[str] ) utilizado en mypy . Y tengo curiosidad por saber si hay un interruptor en la versión 3.6 de Python nativa para lograr los dos puntos que dije anteriormente.

¿Es eso posible? Tal vez mypy podría hacerlo, pero preferiría usar la comprobación de tipos del estilo Python-3.6 (como a: List[str] ) en lugar del estilo de comentario (como # type List[str] ) utilizado en mypy. Y tengo curiosidad por saber si hay un interruptor en la versión 3.6 de Python nativa para lograr los dos puntos que dije anteriormente.

Python no hará esto por ti; puede usar mypy para obtener la verificación de tipos (y el verificador incorporado de PyCharms también debería hacerlo). Además de eso, mypy tampoco le restringe a que solo escriba comentarios # type List[str] , puede usar anotaciones variables como lo hace en Python 3.6, por lo que a: List[str] funciona igual de bien.

Con mypy como está, debido a que el lanzamiento es nuevo, deberá instalar typed_ast y ejecutar mypy con --fast-parser y --python-version 3.6 como se documenta en los documentos de mypy . Esto probablemente cambiará pronto, pero por ahora los necesitará para que funcione sin problemas

Actualización: --fast-parser y --python-version 3.6 no son necesarios ahora.

Después de hacer eso, mypy detecta la incompatibilidad de la segunda operación en su a: List[str] muy bien. Digamos que su archivo se llama tp_check.py con declaraciones:

 from typing import List a: List[str] = [] a.append('a') a.append(1) print(a) 

Ejecutando mypy con los argumentos mencionados (primero debes pip install -U typed_ast ):

 python -m mypy --fast-parser --python-version 3.6 tp_check.py 

atrapa el error:

 tp_check.py:5: error: Argument 1 to "append" of "list" has incompatible type "int"; expected "str" 

Como se señaló en muchas otras respuestas sobre las sugerencias de tipos con Python , mypy y los mypy PyCharm son los que realizan la validación, no Python en sí . Python no usa esta información actualmente, solo la almacena como metadatos y la ignora durante la ejecución.

Las sugerencias de tipo están totalmente destinadas a ser ignoradas por el tiempo de ejecución de Python, y son verificadas solo por herramientas de terceros como mypy y el verificador integrado de Pycharm. También hay una variedad de herramientas de terceros menos conocidas que realizan la comprobación de tipos en tiempo de comstackción o en tiempo de ejecución utilizando anotaciones de tipo, pero la mayoría de la gente utiliza mypy o el comprobador integrado AFAIK de Pycharm.

De hecho, dudo que la verificación de tipos alguna vez se integre en Python propiamente dicho en el futuro previsible; consulte la sección ‘no objectives’ de PEP 484 (que introdujo anotaciones de tipo) y PEP 526 (que introdujo anotaciones de variables), así como como los comentarios de Guido aquí .

Personalmente, me complacería que la verificación de tipos esté más integrada con Python, pero no parece que la comunidad de Python en general esté preparada o dispuesta a ese cambio.

La última versión de mypy debe comprender tanto la syntax de anotación variable de Python 3.6 como la syntax de estilo de comentario. De hecho, las anotaciones variables fueron básicamente la idea de Guido en primer lugar (Guido es actualmente parte del equipo mypy), básicamente, el soporte para anotaciones de tipo en mypy y en Python se desarrolló de forma bastante simultánea.

Las anotaciones de tipo en Python no están destinadas a ser de tipo. Cualquier cosa que involucre la dependencia de tipo estático en tiempo de ejecución significaría cambios tan fundamentales que ni siquiera tendría sentido seguir llamando al lenguaje resultante “Python”.

Tenga en cuenta que la naturaleza dinámica de Python PERMITE que una compile una herramienta externa, utilizando el código de python puro, para realizar la verificación de tipos de tiempo de ejecución. Haría que el progtwig se ejecute (muy) lentamente, pero tal vez sea adecuado para ciertas categorías de prueba.

Para estar seguro, uno de los fundamentos del lenguaje Python es que todo es un objeto, y que puede intentar realizar cualquier acción en un objeto en tiempo de ejecución. Si el objeto no tiene una interfaz que se ajuste a la operación intentada, fallará, en tiempo de ejecución.

Los lenguajes que son por naturaleza tipificados estáticamente funcionan de una manera diferente: las operaciones simplemente deben estar disponibles en los objetos cuando se prueban en tiempo de ejecución. En el paso de comstackción, el comstackdor crea los espacios y las ranuras para los objetos apropiados en todo el lugar y, al tipear no conforme, rompe la comstackción.

La comprobación de tipos de Python permite que cualquier número de herramientas haga exactamente eso: romper y advertir en un paso antes de ejecutar la aplicación (pero es independiente de la comstackción en sí). Pero la naturaleza del lenguaje no se puede cambiar para que realmente requiera que los objetos se cumplan en tiempo de ejecución, y el hecho de escribir y romper el paso de comstackción en sí sería artificial.

Sin embargo, se puede esperar que las versiones futuras de Python puedan incorporar la verificación de tipo en tiempo de comstackción en el mismo tiempo de ejecución de Python, probablemente a través de un interruptor de línea de comando opcional. (No creo que alguna vez sea el valor predeterminado, al menos para no romper la comstackción, tal vez se pueda establecer como predeterminado para emitir advertencias)

Por lo tanto, Python no requiere verificación de tipos estática en tiempo de ejecución porque dejaría de ser Python. Pero al menos existe un lenguaje que hace uso tanto de objetos dynamics como de escritura estática: el lenguaje Cython, que en la práctica funciona como un superconjunto de Python. Uno debería esperar que Cython incorpore la nueva syntax de sugerencia de tipo para que sea la statement de tipo real muy pronto. (Actualmente utiliza una syntax diferente para las variables de tipo estático opcional)