Updated manylinux naming and compatibility profile definition
proposal, to be considered in combination with the
(competing/complementary?) manylinux2014 proposal in
PEP 599.
Per GH-560, the current definition of `python_version` is not compatible
with a 2+ digit major or minor version. There were no objections to
changing the definition to more accurately reflect the semantic content
intended to be conveyed (i.e. the major and minor version).
* PEP 394: Distributions can choose what does python mean
Co-Authored-By: Petr Viktorin <encukou@gmail.com>
* fixup! PEP 394: Distributions can choose what does python mean
* fixup! PEP 394: Distributions can choose what does python mean
* fixup! PEP 394: Distributions can choose what does python mean
* PEP 394: Keep version agnostic shebang recommendation
This update reverts back to the version agnostic "python" invocation
as the default recommendation for developers, and rewords the
rest of the PEP accordingly.
In particular, it makes it clear that publishers are free to adopt
the attitude of "we assume you are using a virtual environment",
while at the same time granting the distributors the freedom they
need to make software with the expectation work correctly when
run directly against a system Python installation.
* Apply suggestions from code review
Co-Authored-By: Carol Willing <carolcode@willingconsulting.com>
* Moving letters around
* Change the abstract
* Remove a paragraph
* ValueError: some authors have more than one email address listed
* Apply suggestions from code review
Co-Authored-By: Petr Viktorin <encukou@gmail.com>
* Address review comments
* Rename section headers
* Push script publishers and users to virtual environments
* Rewording
* Remove "preferred" shebang line wording
* Change post date
* Little tweaks
* Address review comments
- Clarify wording on "older" Linux distros
- Remove discussion aroung Python 4.0
- use baseline feature release and incremental feature release
rather than major/minor feature release
- introduce a new "feature_complete" flag on sys.version_info
to allow the branch state to be inspected at runtime
- impose a runtime feature detection requirement on all features
added in incremental feature releases
Alternative to PEP 596 that aims to reduce feature delivery latency
by giving ourselves access to a new, less disruptive, feature
delivery vehicle, rather than by increasing the frequency with
which we deploy our existing disruptive feature delivery vehicle.
The example with `Concrete` and `Template` is supposed to highlight that adding properties to a protocol in the implementation of a method is not supported, and does not add to the required signature of the protocol.
However, this also has the problem of `Concrete` not being a `Template` anyway because it is missing that `method`.
native-api
Thomas Kluyver
Dustin Ingram
Paul Ganssle
Brett Cannon
Mariatta
Ned Deily
Miro Hrončok
Łukasz Langa
Min ho Kim
Aliaksei Urbanski
Chris Martin
Nick Coghlan
Ben Kooiman-Cox
Barry Warsaw
Peter Schmidt
July Tikhonov
Inada Naoki
Guido van Rossum
Dima Boger
Harmon
Julien Palard
Mark Mendoza
Hugo
Ivan Levkivskyi
Victor Stinner