For the current code I am writing, this proposal will fulfill my number one wish, which is exhaustiveness matching for enumerations. Where previously I used e.g. class Status(enum.Enum): Started = 'STARTED' Finished = 'FINISHED' def example(status: Status) -> int: if status is Status.Started: return 1 elif status is Status.Finished: return 2 else: assert False, 'Impossible' I could now use Status2 = Literal['STARTED', 'FINISHED'] def example(status: Status2) -> int: if status == 'STARTED': return 1 elif status 'FINISHED': return 2 else: assert_never(status) where `assert_never` is as discussed in https://github.com/python/mypy/issues/5818. Of course, I would prefer to keep using Enums. That would require the type checker to consider `Status` similarly to `Literal[Status.Started, Status.Finished]`. This is what TypeScript does with its "const enums". The PEP does not discuss this particular point. Ran
where `assert_never` is as discussed in https://github.com/python/mypy/issues/5818.
I think it makes sense to discuss this use case with assert_never in the PEP
Yes, I think an enum should be equivalent to union of all its values. IIRC this is already required by PEP 484, but was never implemented. We cab re-emphasize it in this PEP. -- Ivan
On Fri, Nov 23, 2018 at 04:30:39PM +0000, Ivan Levkivskyi wrote:
Thanks for pointing that out. I hadn't noticed that this appears in PEP484. The section "Support for singleton types in unions"[0] discusses this issue and has a similar example at the end. I think treating an Enum as (approximately) a union of singleton types is a good way to make that example work. [0] https://www.python.org/dev/peps/pep-0484/#support-for-singleton-types-in-uni... Ran
Thanks! I'll look into making those changes later tonight. Regarding the discussion about enums and exhaustiveness checks: the reason I decided to avoid discussing any form of exhaustiveness checking in draft was because I felt exhaustiveness checking really had more to do with the semantics of unions rather the anything related to literal types. That said, I agree that adding a section reiterating that enums should be treated as (approximately) the union of their values is a good idea -- and if that gives us a way of writing exhaustiveness checks via the "assert_never" technique, even better! I'll add a section about that later tonight as well. -- Michael On Fri, Nov 23, 2018 at 1:31 PM Ran Benita <ran234@gmail.com> wrote:
where `assert_never` is as discussed in https://github.com/python/mypy/issues/5818.
I think it makes sense to discuss this use case with assert_never in the PEP
Yes, I think an enum should be equivalent to union of all its values. IIRC this is already required by PEP 484, but was never implemented. We cab re-emphasize it in this PEP. -- Ivan
On Fri, Nov 23, 2018 at 04:30:39PM +0000, Ivan Levkivskyi wrote:
Thanks for pointing that out. I hadn't noticed that this appears in PEP484. The section "Support for singleton types in unions"[0] discusses this issue and has a similar example at the end. I think treating an Enum as (approximately) a union of singleton types is a good way to make that example work. [0] https://www.python.org/dev/peps/pep-0484/#support-for-singleton-types-in-uni... Ran
Thanks! I'll look into making those changes later tonight. Regarding the discussion about enums and exhaustiveness checks: the reason I decided to avoid discussing any form of exhaustiveness checking in draft was because I felt exhaustiveness checking really had more to do with the semantics of unions rather the anything related to literal types. That said, I agree that adding a section reiterating that enums should be treated as (approximately) the union of their values is a good idea -- and if that gives us a way of writing exhaustiveness checks via the "assert_never" technique, even better! I'll add a section about that later tonight as well. -- Michael On Fri, Nov 23, 2018 at 1:31 PM Ran Benita <ran234@gmail.com> wrote:
participants (3)
-
Ivan Levkivskyi -
Michael Lee -
Ran Benita