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.

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.

Indeed, I don't think that's appropriate. Also, it's not about ++ in general but a particular use of it.

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.

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 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
instead?

But I agree that it's not worth doing it only for "*p++" anyway.

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<ncoghlan@gmail.com>  
>> 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.

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,