Tengo la siguiente función de Python (escrita):
from typing import overload, Literal, NoReturn @overload def check(condition: Literal[False], msg: str) -> NoReturn: pass @overload def check(condition: Literal[True], msg: str) -> None: pass def check(condition, msg): if not condition: raise Exception(msg)El verificador de tipos Pyright se queja:
Overloaded function implementation is not consistent with signature of overload 1 Function return type "NoReturn" is incompatible with type "None" Type cannot be assigned to type "None" Estoy confundido por esto: Pyright aparentemente no puede determinar que la check siempre arrojará un error si la condición es False . ¿Cómo puedo masajear esto para que funcione?
Publiqué esto en el rastreador de problemas de Pyright y me informaron que tenía que agregar una anotación Union[NoReturn, None] a la implementación de check para resolver el error:
[Esto] cae fuera de las reglas de pyright para la inferencia del tipo de devolución. Pyright inferirá un tipo NoReturn solo en el caso de que todas las rutas de código generen una excepción. Es bastante común que algunas rutas de código generen una excepción, y produciría muchos falsos positivos si pyright incluyera NoReturn en la unión en ese caso, por lo que NoReturn siempre se elide de una unión en un tipo de retorno inferido.
Mypy no tiene ningún soporte para la inferencia de tipo de devolución, lo que explica por qué esto no ocurre para mypy.
La forma correcta de anotar esto es incluir un Ninguno | Tipo de devolución NoReturn para la implementación.
Desafortunadamente, esto anula el propósito de las sobrecargas en primer lugar, que es permitir que PyRight de los argumentos cuándo NoReturn es el tipo de devolución. Pregunté si es posible usar overload para expresar condicionalmente NoReturn al verificador de tipos. Aparentemente no es :
Desafortunadamente, pyright no puede tomar esta determinación debido a su arquitectura central. La "accesibilidad" de los nodos dentro de un gráfico de flujo de código no puede basarse en evaluaciones de tipo porque las evaluaciones de tipo dependen de la accesibilidad de los nodos de flujo de código. Para evitar este problema del huevo y la gallina, la lógica que determina la accesibilidad realiza algunas comprobaciones básicas para determinar si la función llamada es potencialmente una función "NoReturn", pero estas comprobaciones básicas no son lo suficientemente sofisticadas para manejar la evaluación de sobrecarga. La evaluación de sobrecargas requiere el evaluador de tipo completo, y eso depende de la accesibilidad.