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.
The previous title gave the impression that this PEP was about
splitting the standard library into separately versioned pieces,
when it's actually a far more modest proposal to improve the
error messages that users receive when pieces are missing, as
well as to provide a standard library API to retrieve the full
list of expected standard library module names.
It also includes a number of other improvements that came up
during the PR review:
- explicitly limit metadata to top level modules
- be clear that private stdlib modules need to be listed
- provide more details on which modules would be optional
- use tkinter and idlelib as additional examples
- provide rationale for packaging modules being mandatory
- provide example error messages for missing submodules
- add subheadings to the design discussion section
- rename Open Questions to Deferred Ideas to avoid scope
creep in the initial proposal
Numeric components in version numbers are expected to be sequences
of ASCII digits, but the PEP didn't actually say that explicitly.
Omission picked up and the `is_canonical` regex in Appendix B corrected
by Frazer McLean.
Also fix various capitalization, style and markup nits found during review
(I'm still not 100% happy with the use of would vs. will everywhere,
but I declare it's good enough. Someone with a degree in English can
fix this up.)
(I also think that the section "After Separator Proposal" could use some editing, but this won't affect acceptance of the PEP.)
* Correct grammar and style.
* Update the "How to teach" section.
* Expand grammar specification.
Signed-off-by: Carol Willing <carolcode@willingconsulting.com>
Organize PEP 570 according to the recommended ordering of sections
defined in PEP 1. This presents the proposal in a more organized and
compelling way.
Notable changes are:
- The content more easily reads in from top to bottom by moving core
content into Abstract, Motivation, Rationale, Specification.
- Making a clear distinction of the impact to library authors and
callers of APIs.
- Fixed-up usage of "parameters" and "arguments" on the context of the
what is being discussed.
- Grammatical edits and simplified wording, while maintaining the core
content and intent of the text.
Eric Snow
Nick Coghlan
Mark Shannon
Mariatta
Petr Viktorin
Michael Lee
Brett Cannon
Barry Warsaw
Guido van Rossum
Vincent Poulailleau
Serhiy Storchaka
Michael J. Sullivan
Sebastian Rittau
James Hamm
Steve Dower
Bernát Gábor
Huang Huang
Batuhan Taşkaya
Jeroen Demeyer
Frazer McLean
Carol Willing
jimbo1qaz
Eric N. Vander Weele
Pablo Galindo
Kevin
Victor Stinner