-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New style unions and special forms #6219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
typeshed should match the implementation. We should add |
Agree with @srittau, but would changing typeshed really be enough to fix the mypy issue? Even if we return something from |
After trying this out locally, I can say for sure that it won't work. Because But, anyways adding new |
|
Handling `Literal` type in annotations. Resolves: #13672 ## Implementation Since Literals are not a fully defined type in typeshed. I used a trick to figure out when a special form is a literal. When we are inferring assignment types I am checking if the type of that assignment was resolved to typing.SpecialForm and the name of the target is `Literal` if that is the case then I am re creating a new instance type and set the known instance field to `KnownInstance:Literal`. **Why not defining a new type?** From this [issue](python/typeshed#6219) I learned that we want to resolve members to SpecialMethod class. So if we create a new instance here we can rely on the member resolving in that already exists. ## Tests https://typing.readthedocs.io/en/latest/spec/literal.html#equivalence-of-two-literals Since the type of the value inside Literal is evaluated as a Literal(LiteralString, LiteralInt, ...) then the equality is only true when types and value are equal. https://typing.readthedocs.io/en/latest/spec/literal.html#legal-and-illegal-parameterizations The illegal parameterizations are mostly implemented I'm currently checking the slice expression and the slice type to make sure it's valid. https://typing.readthedocs.io/en/latest/spec/literal.html#shortening-unions-of-literals --------- Co-authored-by: Carl Meyer <[email protected]> Co-authored-by: Alex Waygood <[email protected]>
Today we got a bug report in
mypy
, thatLiteral[1] | Literal[2]
is not supported: python/mypy#11426Currently this happens on 3.10:
This happens because
mypy
treats|
as a regular__or__
operator. And_SpecialForm
does not have this method. We have two ways to solve this:mypy
. This is quite easy, but I don't think that this is a good way__or__
method to_SpecialForm
type, just like it is done incpython
: https://github.com/python/cpython/blob/14a4fce457033412278ca9a056787db424310dc3/Lib/typing.py#L396-L397 This way we can be suremypy
will just work! πThere are several notes:
_SpecialForm
s that raiseTypeError
when used with|
. Example:Final | int
. But, this happens becauseFinal
is not allowed forUnion
. But, operator is supported. So, I guess this should be handled by a typechecker itselfTypedDict
is not special intypeshed
:typeshed/stdlib/typing.pyi
Lines 57 to 58 in f4143c4
|
is supported by it:TypeVar
is a separate class, not a special form. But, we can useT | S
in runtime as well.I will send a PR with my proposal. We can work from there! π
The text was updated successfully, but these errors were encountered: