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.
Guido van Rossum
Barry Warsaw
Michael Lee
Vincent Poulailleau
Serhiy Storchaka
Nick Coghlan
Michael J. Sullivan
Petr Viktorin
Sebastian Rittau
James Hamm
Eric Snow
Steve Dower
Bernát Gábor
Mark Shannon
Huang Huang
Batuhan Taşkaya
Jeroen Demeyer
Frazer McLean
Carol Willing
jimbo1qaz
Eric N. Vander Weele
Pablo Galindo
Kevin
Victor Stinner
Jukka Lehtosalo
Brett Cannon
Mariatta