[issue12188] PEP 7, C style: add ++ policy and explanation
New submission from Terry J. Reedy <tjreedy@udel.edu>: In response to a discussion of a patch removing 'useless' post-increments, (which issue has apparently come up before) Guido posted "> Sorry to butt in here, but I agree with Eric that it was better
A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug. ---------- assignee: docs@python components: Documentation messages: 136991 nosy: docs@python, terry.reedy priority: normal severity: normal status: open title: PEP 7, C style: add ++ policy and explanation _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by Eric V. Smith <eric@trueblade.com>: ---------- nosy: +eric.smith _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by Eli Bendersky <eliben@gmail.com>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Ezio Melotti <ezio.melotti@gmail.com> added the comment: I'm not sure it's worth adding this to the PEP 7. The PEP is about conventions and style not idioms. PEP 8 has a section about "Programming Recommendations" that contains a few idioms, but since PEP 7 doesn't have an equivalent section, I think that explaining this idiom (and not others) will look out of place. ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by STINNER Victor <victor.stinner@haypocalc.com>: ---------- nosy: +haypo _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Antoine Pitrou <pitrou@free.fr> added the comment: Indeed, I don't think that's appropriate. Also, it's not about ++ in general but a particular use of it. ---------- nosy: +gvanrossum, pitrou resolution: -> rejected status: open -> pending type: -> feature request _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Eric V. Smith <eric@trueblade.com> added the comment: But don't you think we should put information like this somewhere, even if it's not in PEP 7? We've had a discussion about this particular issue (idiomatic pointer increments when appending to a buffer) at least twice, and there's also the recent "if (const == variable)" issue that feels similar to me. It seems to me that recording these decisions somewhere has value, just so we don't have to revisit them. ---------- status: pending -> open _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Ezio Melotti <ezio.melotti@gmail.com> added the comment: If there are a few of these idioms, I'm not against adding a new section to PEP 7 (something like the "Programming Recommendations" section in the PEP 8). It's just not worth doing it for the "*p++ = x;" idiom alone IMHO. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Antoine Pitrou <pitrou@free.fr> added the comment:
If these are recommandations, perhaps we should put them in the devguide instead? But I agree that it's not worth doing it only for "*p++" anyway. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: We have a second item for the PEP (or Guide) section (but I think I prefer in the PEP so as to have one place to look for such things.). So I changed the title a bit. On 6/10/2011 3:49 PM, Guido van Rossum wrote:
[I understand this rationale too; I forget what I actually did when I was writing C.]
[I suspect I did this.]
I bet there will be more things for a new section. ---------- title: PEP 7, C style: add ++ policy and explanation -> PEP 7 (or guide) add C style policies and explanation type: feature request -> versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by Eli Bendersky <eliben@gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
anthony shaw <anthonyshaw@apache.org> added the comment: Hi, This discussion came to a stop, but it doesn't seem conclusive. PEP discussions are now in GitHub on https://github.com/python/peps/issues so I'm going to close this BPO issue. There is no additional section in PEP 7 for this level of detail, there is also no tooling in place (afaik) to retroactively apply or inspect these types of issues, so this would need to be discussed in the PEP issue, ---------- nosy: +anthonypjshaw stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue12188> _______________________________________
Changes by Eric V. Smith <eric@trueblade.com>: ---------- nosy: +eric.smith _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by Eli Bendersky <eliben@gmail.com>: ---------- nosy: +eli.bendersky _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Ezio Melotti <ezio.melotti@gmail.com> added the comment: I'm not sure it's worth adding this to the PEP 7. The PEP is about conventions and style not idioms. PEP 8 has a section about "Programming Recommendations" that contains a few idioms, but since PEP 7 doesn't have an equivalent section, I think that explaining this idiom (and not others) will look out of place. ---------- nosy: +ezio.melotti _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by STINNER Victor <victor.stinner@haypocalc.com>: ---------- nosy: +haypo _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Antoine Pitrou <pitrou@free.fr> added the comment: Indeed, I don't think that's appropriate. Also, it's not about ++ in general but a particular use of it. ---------- nosy: +gvanrossum, pitrou resolution: -> rejected status: open -> pending type: -> feature request _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Eric V. Smith <eric@trueblade.com> added the comment: But don't you think we should put information like this somewhere, even if it's not in PEP 7? We've had a discussion about this particular issue (idiomatic pointer increments when appending to a buffer) at least twice, and there's also the recent "if (const == variable)" issue that feels similar to me. It seems to me that recording these decisions somewhere has value, just so we don't have to revisit them. ---------- status: pending -> open _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Ezio Melotti <ezio.melotti@gmail.com> added the comment: If there are a few of these idioms, I'm not against adding a new section to PEP 7 (something like the "Programming Recommendations" section in the PEP 8). It's just not worth doing it for the "*p++ = x;" idiom alone IMHO. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Antoine Pitrou <pitrou@free.fr> added the comment:
If these are recommandations, perhaps we should put them in the devguide instead? But I agree that it's not worth doing it only for "*p++" anyway. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: We have a second item for the PEP (or Guide) section (but I think I prefer in the PEP so as to have one place to look for such things.). So I changed the title a bit. On 6/10/2011 3:49 PM, Guido van Rossum wrote:
[I understand this rationale too; I forget what I actually did when I was writing C.]
[I suspect I did this.]
I bet there will be more things for a new section. ---------- title: PEP 7, C style: add ++ policy and explanation -> PEP 7 (or guide) add C style policies and explanation type: feature request -> versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
Changes by Eli Bendersky <eliben@gmail.com>: ---------- nosy: -eli.bendersky _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue12188> _______________________________________
anthony shaw <anthonyshaw@apache.org> added the comment: Hi, This discussion came to a stop, but it doesn't seem conclusive. PEP discussions are now in GitHub on https://github.com/python/peps/issues so I'm going to close this BPO issue. There is no additional section in PEP 7 for this level of detail, there is also no tooling in place (afaik) to retroactively apply or inspect these types of issues, so this would need to be discussed in the PEP issue, ---------- nosy: +anthonypjshaw stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue12188> _______________________________________
participants (7)
-
anthony shaw -
Antoine Pitrou
-
Eli Bendersky
-
Eric V. Smith
-
Ezio Melotti
-
STINNER Victor
-
Terry J. Reedy