Change PEP 13 to make the Council Election use regular (multiwinner) approval voting, the same thing used for the PSF board elections, instead of restricting the number of votes to the number of seats in the Council.
Also updates the NEP 29 section to cover the latest wording
of that proposal, and makes it clear that mere acceptance
of the PEP doesn't prevent us from ever changing the release
process again.
Review PEP providing shared background for PEPs 602 and 605, covering both
common problem statements, and key differences in the proposals to address
those problems.
Co-Authored-By: Steve Dower <steve.dower@microsoft.com>
Co-Authored-By: Łukasz Langa <lukasz@langa.pl>
* Reword PEP 503 to match pip's URL lookup behavior
Clarify that the "filename" displayed in the anchor tag refers to the
final path component of the URL (instead of, say, the filename parameter
in the HTTP Content-Disposition header).
This matches pip's behavior: The URL's final path component is used to
determine the artifact's name (for selection), and its filename after
download.
* Replace "an URL" with "a URL"
* PEP 605: Add example user-facing docs
* example What's New subsection
* example alpha, beta, and rc announcements
* fix Python-Requires recommendation
* add rationale for allowing mid-stream alpha releases
* Stable ABI builds prior to 3.8 are also allowed
* Alphas are also for application testing
* Also put an ABI break marker in commit summaries
* Change ABI management to encourage pre-built wheels
* Actually dedicate a subsection to the 2 year cadence
* Update naming discussion for proposal changes
* Add discussion section for the pre-freeze flag
* Make the abstract much shorter (as suggested by Antoine Pitrou)
* Move example time line up and add pictures (based on PEP 602 images)
* Clarify 4 month window for X.Y.0a1 preparation
Co-Authored-By: Steve Dower <steve.dower@microsoft.com>
* proposes the regular publication of production-ready beta releases rather than making full X.Y.0 feature releases more common
* PEP 598 is being withdrawn in favour of this proposal
* originally drafted in collaboration with @zooba, @aeros167, and @h-vetinari
Matching the symbols permitted for x86_64 by GCC_4.3.0 require a limit of GCC_4.5.0 on i686 CentOS 6.
This does create the risk that 32-bit extension modules using `__extendxftf2` may not actually be portable to all 2010 era systems, but most of those other than RHEL/CentOS 6 have already hit the end of their respective support periods.
* Add PEP-0604 to describes an extension to Python language, which aims to add a complementary
syntax to write ``Union[X,Y]`` and ``Optional[X]`` easier.
* Add sample with metaclass with __invert__ and/or __or__
* Remove operator __revert__
* Change title of pep-604
Uses static last stable version tag (v0.11.1), instead of dynamic
branch name (develop), when pointing to documents in the TUF
repository. This makes them more prone to become outdated but less
prone to 404.
Note, that the two referenced tuf publications are also available
under more permanent, albeit paywalled DOIs:
[2] https://doi.org/10.1145/1866307.1866315
[13] https://doi.org/10.1145/1455770.1455841
* Add PEP-0604 to describes an extension to Python language, which aims to add a complementary
syntax to write ``Union[X,Y]`` and ``Optional[X]`` easier.
* Add sample with metaclass with __invert__ and/or __or__
* Remove operator __revert__