This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: PEP 7 (or guide) add C style policies and explanation
Type: Stage: resolved
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: docs@python Nosy List: anthonypjshaw, docs@python, eric.smith, ezio.melotti, gvanrossum, pitrou, terry.reedy, vstinner
Priority: normal Keywords:

Created on 2011-05-26 18:19 by terry.reedy, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (8)
msg136991 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-05-26 18:19
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
> before. There is a common idiom, *pointer++ =<something>, and
> whenever you see that you know that you are appending something to an
> output buffer. Perhaps the most important idea here is that this
> maintains the *invariant* "pointer points just after the last thing in
> the buffer". Always maintaining the invariant is better than trying to
> micro-optimize things so as to avoid updating dead values. The
> compiler is better at that."

A condensed version of the above added to PEP 7 would help new developers see the usage as local idiom rather than style bug.
msg137111 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-05-28 09:04
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.
msg137808 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-06-07 11:23
Indeed, I don't think that's appropriate. Also, it's not about ++ in general but a particular use of it.
msg137809 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-06-07 11:36
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.
msg137814 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2011-06-07 11:51
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.
msg137818 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-06-07 12:02
> 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.

If these are recommandations, perhaps we should put them in the devguide

But I agree that it's not worth doing it only for "*p++" anyway.
msg138143 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-06-11 01:03
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:
> On Wed, Jun 8, 2011 at 8:12 AM, Nick Coghlan<>  
>> I actually thought Brett's rationale in the checkin comment was
>> reasonable (if you get in the habit of putting constants on the left,
>> then the classic "'=' instead of '=='" typo is a compiler error
>> instead of a reassignment).

[I understand this rationale too; I forget what I actually did when I was writing C.]

> I really like consistency across the code base. I really don't like
> constant-on-the-left, and it's basically not used in the current
> codebase. Please be consistent and don't start using it.

[I suspect I did this.]
>> Call it a +0 in favour of letting people put constants on the left in
>> C code if they prefer it that way, so long as any given if/elif chain
>> is consistent in the style it uses.
> Sorry, I give it a -1. (I'd like to be able to read the codebase still... :-)

I bet there will be more things for a new section.
msg341951 - (view) Author: anthony shaw (anthonypjshaw) * (Python triager) Date: 2019-05-09 01:07

This discussion came to a stop, but it doesn't seem conclusive.

PEP discussions are now in GitHub on 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,
Date User Action Args
2022-04-11 14:57:17adminsetgithub: 56397
2019-05-09 01:07:47anthonypjshawsetstatus: open -> closed

nosy: + anthonypjshaw
messages: + msg341951

stage: resolved
2011-11-12 05:04:14eli.benderskysetnosy: - eli.bendersky
2011-06-11 01:03:14terry.reedysettype: enhancement ->
title: PEP 7, C style: add ++ policy and explanation -> PEP 7 (or guide) add C style policies and explanation
messages: + msg138143
versions: + Python 2.7, Python 3.2, Python 3.3
2011-06-07 12:02:52pitrousetmessages: + msg137818
2011-06-07 11:51:25ezio.melottisetmessages: + msg137814
2011-06-07 11:36:32eric.smithsetstatus: pending -> open

messages: + msg137809
2011-06-07 11:23:55pitrousetstatus: open -> pending

nosy: + pitrou, gvanrossum
messages: + msg137808

type: enhancement
resolution: rejected
2011-05-30 15:17:27vstinnersetnosy: + vstinner
2011-05-28 09:04:10ezio.melottisetnosy: + ezio.melotti
messages: + msg137111
2011-05-27 03:13:52eli.benderskysetnosy: + eli.bendersky
2011-05-26 19:37:54eric.smithsetnosy: + eric.smith
2011-05-26 18:19:32terry.reedycreate