Sebastian Rittau
Sebastian Rittau
At least in the sort term we should revert in cases where literals cause problems and in the future only use literals where it's unlikely that the literal gets assigned...
Actually, at least in mypy the following already works: ```python FOO: Final = 1 BAR: Final = 2 x = FOO reveal_type(FOO) # type: Literal[1] reveal_type(x) # type: int ```...
Cc @rchen152 @erictraut @pradeep90 for feedback on using `X: Final = 3` in stubs.
Also Cc @sobolevn as "`Literal` master".
In #7259 pytype currently fails with "ParseError: Default value for CRITICAL: $external$typing_extensions.Final can only be '...', got LITERAL(50)", so we'd at least need to fix that and of course flake8-pyi.
> > > Anyway, if different type checkers have interpreted PEP 586 differently, it seems to me that we should avoid using literal types in stubs in contexts where their...
I wouldn't want to extend this moratorium past the end of the year (2022). I hope we'll find a solution until then. Otherwise I suggest that typeshed will continue to...
> This might be a silly suggestion, but couldn't those non-types dependencies somehow be specified as optional/extra dependencies that are installed in typeshed CI, but not by default for end-users...
> I think it's important to note that this only works in stub files, if you have `from __future__ annotations` enabled, or if you use `-> "IdentityFunction"` instead of `->...
Options 2 or 3 would only work within function defs, not in variable annotations, though.