* PEP 639: Reframe core metadata update as discrete proposal per PEP 643
* PEP 639: Clean up formatting, syntax, spelling, headers and lists
* PEP 639: Rewrite to reflect License-Expression field and depr process
* PEP 639: Update examples, current tools survey, links and more
* PEP 639: Add PEP 621, expand/move examples & reorganize/shorten headings
* PEP 639: Further specify and clarify license file handling
* PEP 639: Add additional ambigous classifiers and tool recommendations
* PEP 639: Rework PEP 621 keys, refine dynamic/globs & add rejected ideas
* PEP 639: Specify license path root & subdirs, & expand examples
* PEP 639: Add license_files dir, rejected ideas & sdist/wheel/installed
* PEP 639: Add PyPI validation of new fields for newly-uploaded files
* PEP 639: Add open isssue for back-filling & reject per-dist licenses
* PEP 639: Add User Scenarios to provide guidance for common use cases
* PEP 639: Update Abstract, Goals, Rationale, Compat. & other sections
* PEP 639: Add terminology section & use consistant, clear & correct terms
* PEP 639: Make refs inline per #2130, add links, fix others & refine text
* PEP 639: Copyedit and proofread for grammar, phrasing, clarity & tone
* PEP 639: Address reviewer and community feedback
* PEP 639: Add custom IDs issue & clarify rejected license key str value
Thanks to Eric Traut who tested all the code examples in Pyright and
raised implementation concerns about ``Self`` type in aliases.
I ran into implementation issues in Pyre too. This is because Pyre
preprocesses things like ``Self`` in an early phase and does alias
resolution in a later phase. Mixing the two would lead to a lot of
hacks.
* Address Guido's comments from initial PR
* Update functions-as-types based on Pradeep's feedback
* Fix some markup, address comments on endpoint example
* Rearrange Motivation and Rationale
* Move the language comparison subsection to Rational
* Fix more markup errors
* Rework "Motivation" section again
Going with Pradeep's suggested order:
- untyped example
- correct types
- partially-typed code
- our proposal
* Fix more lint errors
* Add a section highlighting a concern about -> readability
* Update the add/wrap/flatmap example
* Wording change suggested by AlexWaygood
* Add missing return annotation
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
* Break up long sentence
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
* Break up long sentence (thanks Jelle)
* Reword awkward sentence (thanks Pradeep)
* Rearrange paragraphs in Motivation
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
A number of cleanups also happened, improving readability of various sections and examples, but the only *semantic* change here is that TypeVarTuples can now be substituted with unbounded tuples (previously that was explicitly forbidden, but we convinced ourselves that there is no reason for that).
* Remove incorrect implementation of pop(). There is an implementation in collections.MutableMapping so it is not needed. Add implementation of __contains__.
* Remove outdated section on differences with PEP 558.
* Elaborate the Abstract
* Add "Misnesting" example
* The return value has already been removed in the public C API macros
* Clarify that converting Py_TYPE() macro was an incompatible change
* Don't convert l-value macros
* Add "Examples of duplication of side effects" section
* Remove the gcc -O0 versus gcc -Og benchmark: it's not relevent for
this PEP.
Brett Cannon
Dimitri Papadopoulos Orfanos
CAM Gerlach
Steven Troxler
Edward O
Pradeep Kumar
Ee Durbin
Matthew Rahtz
Paul Moore
Julin S
Mark Shannon
Ram Rachum
bobozi-cmd
Pablo Galindo
Hugo van Kemenade
Adam Turner
Victor Stinner
Chris Angelico
Tim Felgentreff
Erlend Egeberg Aasland
Jelle Zijlstra
Ofek Lev