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.)