| msg232842 - (view) |
Author: Alyssa Coghlan (ncoghlan) *  |
Date: 2014-12-18 00:08 |
| 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 |
|
|
| msg233226 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2014-12-31 01:54 |
| 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. |
|
|
| msg233243 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2014-12-31 14:51 |
| On Dec 31, 2014, at 01:54 AM, Nick Coghlan wrote: >As we've started working through the post-release PEP 440 changes, I think >this is definitely worthy of a separate PEP. I'm open to discussion and ideas, but I want to caution against spreading information about the PEP (and more largely, enhancing Python) process over too many documents. PEP 1 and the process has worked well I think because it's relatively easy to find information on the process in a concise format. I also don't think we necessarily need to cross-and-dot every I-and-T. Flexibility can be a good thing too. |
|
|
| msg233263 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2014-12-31 18:13 |
| 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 :) |
|
|
| msg312523 - (view) |
Author: Cheryl Sabella (cheryl.sabella) * |
Date: 2018-02-22 00:40 |
| Pull request: https://github.com/python/peps/pull/577 |
|
|
| msg312528 - (view) |
Author: Alyssa Coghlan (ncoghlan) * |
Date: 2018-02-22 02:43 |
| 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 :) |
|
|
| msg335656 - (view) |
Author: Cheryl Sabella (cheryl.sabella) * |
Date: 2019-02-15 23:34 |
| Closing as third party since this moved to the PEP repository. |
|
|