Refine "non-standard" phrasing in PEP 735
One of the Poetry maintainers noted tha the current phrasing could be
read as a negative take on `poetry` and `pdm` using "non-standard"
data.
At the same time, it's important to be clear that the problem being
solved here is not adequately solved by the existing tools due to the
lack of an existing underlying standard.
This rephrasing tries to balance these two concerns, describing the
current behaviors as 'tool specific' and focusing on "standardization"
(positive) rather than "non-standardization" (negative).
Example sections on:
- When to use TypeIs
- How to write a safe TypeIs
- TypeIs vs. TypeGuard
Also note the implementations in typing-extensions, pyright, and pyanalyze.
* PEP 696: consolidate discussion of constraint solving.
Consolidates discussion of usage of defaults in constraint solving in
the "Function Defaults" section, to make it clear that this is
experimental and unspecified.
* PEP 696: Explicitly call out that defaults do not affect subtyping.
* Moves TypeVarTuple discussion so the text flows better. Otherwise, it
feels to me like an awkward interlude between the paragraph
introducing rules and the actual rules.
* In sections where the text uses `T1` and `T2` as TypeVar names, changes
the examples to use the same names.
* Fix subtyping relationship in "Bound Rules."
* Spell out subclassing rules in the text, rather than leaning so much on the example.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
This loosens the statements about builds and configure needing to
Break and instead changes this to a mere build/configure time warning.
This is in line with how we treat platforms that are not on a support
Tier (of which there are many). Doing anything else would basically
be unreasonable punshiment for anything in our support Tiers that then
loses its official PEP-11 support for whatever reason.
Discussed in https://discuss.python.org/t/proposed-update-to-pep-11-on-unsupporting-a-platform-less-draconian-measures/44065.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
- Minor corrections / typo fixes
- Use a ref role for `use_cases` link. As currently written, it
renders incorrectly to a relative link to a `use_cases` page.
- Fix header style for Use Cases Appendix
- Add an explicit Compatibility section to Rationale
Future compatibility and designing the Dependency Groups data to be
extensible is a particular area of concern within the PEP. Although it
is addressed to some degree in the Specification, this small note in
the Rationale clarifies that compatibility with spec extensions is a
---------
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
As announced in https://discuss.python.org/t/43534,
I'm stepping down as the contact for powerpc64le.
This demotes the platform to Tier 3 (which is the right
place for it, IMO).
- Remove the PEP 723 use-case
- Change to non-normalized names which require normalization
- Update the reference implementation to normalize
- Clarify the meaning of an Include
- Forbid cycles in includes
- Add a section on validation and compatibility which clearly defines
future-compatible behavior
- Remove 'include list' from open issues
- Add 'includes of `[project]` tables' to open issues
Added the note from SC regarding expanding
the scope to include docstrings in the
standard library.
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
* PEP 726: Fix error message description
Zero is a non-negative number, but since zero is being excluded here, the
check is really ensuring that it is a positive number.
* s/overriden/overridden/
---------
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
The passage in the PEP misleads its readers into believing, that
unpacking in comprehensions is supported. This is not the case, as
presented by the abstract itself:
> This PEP does not include unpacking operators inside list, set and
> dictionary comprehensions although this has not been ruled out for
> future proposals.
(Historically, the PEP originally did propose this, but that part of
the PEP was rejected, and the abstract wasn't completely updated.)
Jelle Zijlstra
Eric Snow
Sergey B Kirpichev
Mariatta
Filipe Laíns
Stephen Rosen
Hugo van Kemenade
William Andrea
Tian Gao
Sviatoslav Sydorenko (Святослав Сидоренко)
Zixuan Li
James Hilton-Balfe
Malcolm Smith
William Woodruff
Eric Traut
Victor Stinner
Brett Cannon
Rebecca Chen
Ethan Furman
Mark Shannon
Gregory P. Smith
Petr Viktorin
T. Wouters
Steve Dower
Joshua Bambrick
Paul Moore
Hugo van Kemenade
Aliaksei Urbanski
Ee Durbin
Chris Angelico
Sebastián Ramírez
John T. Wodder II
Blazej Michalik
Jean Abou-Samra