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
{{ message }}
Repository navigation
Regression: error messages for literal expressions in invalid places are worse #5989
After #5947 (basic end-to-end support for literal types) lands, we'll start deferring some of the "invalid type" checks to the semantic analysis layer by wrapping them into a 'RawLiteralType'. This can, in some cases have an unintended side-effect of making some error messages worse. For example, writing T = TypeVar('T', bound=1) previously used to report error messages like "TypeVar 'bound' must be a type"; now they report error messages like E: Invalid type: try using Literal[1] instead?.
We ran into a similar case with 'NewType' -- in that case, we added some special-casing to restore the original error message. We could do the same thing here, and for other similar "type-alias-like" constructs such as NamedTuple or TypedDict.
Alternatively, we could explore adding TypeOfAny.invalid_type as Ivan suggests here -- this could also potentially help us resolve #4030 at the same time.
Note to self: if it looks like literal types aren't going to make it into the next mypy release, we should at least fix this error and/or change any existing errors to make sure we never recommend using 'Literal[...]'. It would be confusing if error messages started talking about literal types before they're actually officially released.
Activity
Remove RawLiteralType synthetic type
Adjust error handling for literals in NewType and TypeVars
Improve error messages related to literal types (#6149)