Support enums in unions per PEP 484 #1803
Comments
|
This should work for other singletons, specifically Ellipsis. (Though it's unclear how its type should be spelled since builtins.ellipsis only exists in the stubs, not in the actual runtime.) |
|
It looks like this would be easier to implement after we support literal types. |
ilevkivskyi
pushed a commit
that referenced
this issue
Jul 8, 2019
Fixes #1803 This diff adds support for performing reachability and narrowing analysis when doing certain enum checks. For example, given the following enum: class Foo(Enum): A = 1 B = 2 ...this pull request will make mypy do the following: x: Foo if x is Foo.A: reveal_type(x) # type: Literal[Foo.A] elif x is Foo.B: reveal_type(x) # type: Literal[Foo.B] else: reveal_type(x) # No output: branch inferred as unreachable This diff does not attempt to perform this same sort of narrowing for equality checks: I suspect implementing those will be harder due to their overridable nature. (E.g. you can define custom `__eq__` methods within Enum subclasses). This pull request also finally adds support for the enum behavior [described in PEP 484][0] and also sort of partially addresses #6366 [0]: https://www.python.org/dev/peps/pep-0484/#support-for-singleton-types-in-unions
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See this PR for PEP 484: python/typing#240
Because we know that Enum classes cannot be further subclassed, picking apart a value that could be a specific enum or some other type by comparing to all possible values of the enum should be enough to conclude that in the "else" clause the value cannot be an instance of that enum any more, so it must be the other type (examples in the linked PEP section).
The text was updated successfully, but these errors were encountered: