You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pitch
Currently, the proposed syntax produces a Name "f" already defined ... [no-redef] error, unlike similar code for non-function values:
# OKx: intx=3
For some complicated function signatures, it would be clearer to provide a single Callable hint than to have argument types
mixed in with the arguments themselves and the return type added after the parameter list. For that matter, the two styles above need not be mutually exclusive:
mypy should report an error only if the types are identical. (Or perhaps compatible; I don't know if there would be use-cases
for the initial type to be a supertype of the one implied by the function annotations.)
This would be consistent with the def statement being a kind of assignment, as the following is currently allowed:
x: intx=3
as well as eliminate the asymmetry between function parameters and "ordinary" names.
The text was updated successfully, but these errors were encountered:
I have wanted this as a way of moving incredibly complicated overload definitions out of the way into a dedicated types file that only needs to be parsed by type checkers. I currently wrap the overloads in if TYPE_CHECKING but that still leaves them in the file, so they still add some runtime overhead, and they are really not intended for most casual readers either, harming readability.
Feature
Allow
as an alternative to
Pitch
Currently, the proposed syntax produces a
Name "f" already defined ... [no-redef]
error, unlike similar code for non-function values:For some complicated function signatures, it would be clearer to provide a single
Callable
hint than to have argument typesmixed in with the arguments themselves and the return type added after the parameter list. For that matter, the two styles above need not be mutually exclusive:
mypy
should report an error only if the types are identical. (Or perhaps compatible; I don't know if there would be use-casesfor the initial type to be a supertype of the one implied by the function annotations.)
This would be consistent with the
def
statement being a kind of assignment, as the following is currently allowed:as well as eliminate the asymmetry between function parameters and "ordinary" names.
The text was updated successfully, but these errors were encountered: