The previous wording could be taken as suggesting that frontends should opt
out of their PEP 517 processing entirely if build-backend was not defined,
whereas it's actually fine to just use the setuptools provided backend that
implements the legacy build semantics.
See bpo-36798.
This update specifies the interplay between f-strings and
the assignment operator. Specifically, it attempts to
clarify how to use assignment operators inside of f-strings.
There is too little time left before the 3.8 release and I don't want Antoine to feel rushed to pronounce. The implementation is mostly complete, so we could land it for 3.8. However, the experience in 3.8 wouldn't be nearly as good, in part because we're still sharing the GIL. Plus, we need more confidence that extension modules won't be severely impacted by the wide-spread use of subinterpreters. Waiting for 3.9 will allow us to address both issues, as well improve performance (especially startup).
- consistently use "discourage" instead of "deprecate" for the zero-fill
behaviour in the existing constructors
- make the implied assumption of positional-only parameters explicit
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 J. Sullivan
Donald Stufft
Nick Coghlan
Hugo
Dominik Gabi
Petr Viktorin
Antoine Pitrou
Christian Heimes
Steve Dower
Mark Shannon
Łukasz Langa
Logan Jones
Victor Stinner
Guido van Rossum
Matthias Bussonnier
Brett Cannon
Barry Warsaw
Eric Snow
Mariatta
Michael Lee
Brett Cannon
Vincent Poulailleau
Serhiy Storchaka