New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PEP 1: Allow Provisional status for PEPs #67266
Comments
As per python-dev discussion [1], filing this as the home for a proposed update to PEP-1 that allows Standards Track PEPs to be granted Provisional status before moving on to Accepted/Final. The new status will be for PEPs where we want to release an initial reference implementation (whether in CPython under PEP-411 or through the PyPA toolchain) before locking down the exact details of the API specification. [1] https://mail.python.org/pipermail/python-dev/2014-December/137622.html |
As we've started working through the post-release PEP-440 changes, I think this is definitely worthy of a separate PEP. I'll take the opportunity to pitch some other changes as well, like separating out the interoperability standards from the informational PEPs like the CPython release process guide, and add new metadata headers to indicate when the reference implementation of a standard is provided by a project other than CPython. We may decide the extra complexity isn't worth it, but after wrangling PEP-440 through to completion under the delegation of authority to distutils-sig, I'd at least like to have the discussion about what we think represents a "necessary, but sufficient" level of process change. |
On Dec 31, 2014, at 01:54 AM, Nick Coghlan wrote:
I'm open to discussion and ideas, but I want to caution against spreading |
The new PEP wouldn't be a permanent one - it would be describing the proposed changes to PEP-1, and the rationale for them. It would be for my own benefit as much as anyone's - if I can't explain the proposed change and its intended benefits clearly in PEP form, its probably a bad idea :) |
Pull request: |
I'll also note that I made my comments above about writing a new PEP prior to the migration to GitHub and the availability of a PR-based workflow for reviewing PEP changes. So consider the PR Cheryl linked and the post at https://mail.python.org/pipermail/python-dev/2018-February/152205.html the replacement for that PEP suggestion :) |
Closing as third party since this moved to the PEP repository. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: