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__
Add a new struct_size field to PyPreConfig and PyConfig structures to
allow to modify these structures in the future without breaking the
backward compatibility.
Remove _config_version fields, replaced by struct_size.
Facebook Research has now funded implementation of
cryptographic signing of packages on PyPI. Per
https://github.com/pypa/warehouse/issues/5247#issuecomment-535278176
this means that PEP 458 now moves out of Deferred
status and into Draft status.
Since the PEP was created, the BDFL-Delegate for
PyPI-related PEPs has shifted, and Donald Stufft
is now the Delegate.