Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker http://bugs.python.org/issue12188 _______________________________________

Ezio Melotti 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 http://bugs.python.org/issue12188 _______________________________________

Antoine Pitrou 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 http://bugs.python.org/issue12188 _______________________________________

Ezio Melotti 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 http://bugs.python.org/issue12188 _______________________________________

Terry J. Reedy 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:

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. ---------- 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 http://bugs.python.org/issue12188 _______________________________________

anthony shaw 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 https://bugs.python.org/issue12188 _______________________________________