This commit adjusts two sections of this PEP that are related to enums.
First, it removes the sections regarding the interaction between enums,
imports, and Any. I wasn't aware that the import behavior described in
that section was mypy-only and isn't codified in PEP 484. So, I decided
to just remove that section entirely -- it didn't feel there was much I
could salvage there.
Instead, I opted to adjust the "invalid parameters" section to explain
in a little more detail why `Literal[Any]` is not allowed.
Second, I split up the section about type narrowing into two.
The first new section is a reminder that PEP 484 requires type checkers
to support certain kinds of exhaustibility checks when working with enums.
To make this more clear, I adjusted the example to be more closer to what
is used in the spec and removed any mention of reachability -- it felt
like a distraction.
The second section focuses back on some neat tricks using Literals that
type checkers may optionally implement. I also tweaked some of the
examples here as suggested in https://github.com/python/peps/pull/993.
This pull request relaxes PEP 586 so that type checkers are now expected
to maintain backwards compatibility on a best-effort basis, rather than
a mandatory basis.
It also rearranges the order in which information is presented: the
section now opens with and focuses on an example of what a too-disruptive
inference strategy would look like.
This commit adds a section discussion how Literal types interact with
Final from PEP 591, if both PEPs are accepted. In short, it states
that type checkers are expected to understand that assignment statements
of the form `var: Final = value` are a way of declaring `var` to
effectively be of type `Literal[value]` in certain cases.
Michael Lee
Guido van Rossum
Vincent Poulailleau
Serhiy Storchaka