Changes by Carol Willing willi...@willingconsulting.com:
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
___
Berker Peksag added the comment:
Thanks!
--
nosy: +berker.peksag
resolution: - fixed
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
Roundup Robot added the comment:
New changeset 0c4006b7c7ff by Berker Peksag in branch 'default':
Issue #16574: Clarify that once a PEP has implemented, it needs be
https://hg.python.org/devguide/rev/0c4006b7c7ff
--
nosy: +python-dev
___
Python
Éric Araujo added the comment:
Patch LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
___
___
Python-bugs-list mailing list
Carol Willing added the comment:
This patch should close this languishing devguide issue. This patch adds
wording suggested by Terry Reedy re: pep documentation reference to section
7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3).
The devguide covers the pep
Terry J. Reedy added the comment:
With respect to editing final peps, I think this issue should be closed. The
current PEP 1 statement accurately describes what we do, which is that in
general we do not edit final peps. Moreover, Chris has not submitted a patch
and I doubt anyone else knows
Martin v. Löwis added the comment:
1. I think that the PEP author has the final say as to what specific text goes
into the PEP. Contributors shouldn't modify other people's PEP without consent
from the author(s).
2. This holds for all stages, including the Final stage. If the PEP author
Barry A. Warsaw added the comment:
On Nov 29, 2012, at 12:16 PM, Martin v. Löwis wrote:
1. I think that the PEP author has the final say as to what specific text
goes into the PEP. Contributors shouldn't modify other people's PEP without
consent from the author(s).
2. This holds for all
Chris Jerdonek added the comment:
Thanks for the feedback. I will post here a devguide patch to include some of
this information in the devguide.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
New submission from Chris Jerdonek:
This issue is to clarify the policy in PEP 1 regarding non-substantive changes
to PEPs in the Final state (minor clarifications, rephrasings, etc).
Currently, PEP 1 says, In general, Standards track PEPs are no longer modified
after they have reached the
Martin v. Löwis added the comment:
I don't think this needs clarification. The status quo is fine.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
___
Chris Jerdonek added the comment:
Are you saying that PEP 1 is correct and that Final PEPs should not be
modified, or that the PEP isn't correct but that it shouldn't be modified?
If the latter, for someone new it's not clear whether minor clarifications are
permitted and if so, how to go
Éric Araujo added the comment:
I think Brett edited PEP 302 a decade after its acceptance.
--
nosy: +brett.cannon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
___
Barry A. Warsaw added the comment:
On Nov 29, 2012, at 12:56 AM, Chris Jerdonek wrote:
Currently, PEP 1 says, In general, Standards track PEPs are no longer
modified after they have reached the Final state.
I agree w/mvl. This is still true, and it doesn't mean PEPs can't be modified
after
Éric Araujo added the comment:
Right, “in general” is good enough to capture what we do. Chris, closing?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16574
___
Chris Jerdonek added the comment:
Okay, so in a comment to issue 15990, Ezio suggested that some clarifying
changes to PEP 362 might be worth making. How would I (or someone else) go
about doing that? Where would they begin?
I think this recent e-mail from Nick applies:
Chris Jerdonek added the comment:
By the way, I don't especially care if the clarification goes in the PEP itself
or not. What's more important is that it be documented *somewhere* (which
could also be the devguide, for example). My interest in knowing the process
is genuine.
--
Brett Cannon added the comment:
Once PEPs reach their final status, I view them basically done if there is more
official docs. For instance, I updated PEP 302 because the import and importlib
docs were not as thorough as they are now thanks to Barry. But now that we have
proper docs I don't
Éric Araujo added the comment:
I think the gist here is that “in general” is good enough, given that there is
unwritten consensus about what edits are possible in the developers’ heads.
Most of the time unwritten knowledge is not good, but (if I get what Martin and
Barry mean correctly) for
Ezio Melotti added the comment:
FTR the reason I suggested to modify PEP 362 is that we are linking to it from
the docs. This means that people will go and read the PEP looking for
clarifications, so the PEP should be clear. In this regard I see the PEP (or
at least the relevant section) as
Chris Jerdonek added the comment:
I think the gist here is that “in general” is good enough, given that there
is unwritten consensus about what edits are possible in the developers’ heads.
As I said, I'm okay with keeping the PEP as is (with in general, etc)
provided a clarification is
Nick Coghlan added the comment:
Yeah, I agree the in general in PEP 1 is enough of a caveat.
The unwritten rules in this particular case are that if something in a PEP is
important enough to be permanently referenced, then it's important enough to be
part of the language spec (either the main
22 matches
Mail list logo
