Title: PEP 7 (or guide) add C style policies and explanation
Type: Stage:
Components: Documentation Versions: Python 3.2, Python 3.3, Python 2.7
Status: open Resolution: rejected
Dependencies: Superseder:
Assigned To: docs@python Nosy List: 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 2011-11-12 05:04 by eli.bendersky.

Messages (7)
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.
Date User Action Args
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