FWIW I'm against forcing braces to be used. Readability is the highest concern, and this should be at the discretion of the contributor. A code formatting tool, or compiler extension is the only proper handle this, and neither are in use or available.
On Tue, Jan 3, 2012 at 7:44 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >> He keeps leaving them out, I occasionally tell him they should always >> be included (most recently this came up when we gave conflicting >> advice to a patch contributor). He says what he's doing is OK, because >> he doesn't consider the example in PEP 7 as explicitly disallowing it, >> I think it's a recipe for future maintenance hassles when someone adds >> a second statement to one of the clauses but doesn't add the braces. >> (The only time I consider it reasonable to leave out the braces is for >> one liner if statements, where there's no else clause at all) > > While this appears to be settled, I'd like to add that I sided with > Benjamin here all along. > > With Python, I accepted a style of "minimal punctuation". Examples > of extra punctuation are: > - parens around expression in Python's if (and while): > > if (x < 10): > foo () > > - parens around return expression (C and Python) > > return(*p); > > - braces around single-statement blocks in C > > In all these cases, punctuation can be left out without changing > the meaning of the program. > > I personally think that a policy requiring braces would be (mildly) > harmful, as it decreases readability of the code. When I read code, > I read every character: not just the identifiers, but also every > punctuation character. If there is extra punctuation, I stop and wonder > what the motivation for the punctuation is - is there any hidden > meaning that required the author to put the punctuation? > > There is a single case where I can accept extra punctuation in C: > to make the operator precedence explicit. Many people (including > myself) don't know how > > a | b << *c * *d > > would group, so I readily accept extra parens as a clarification. > > Wrt. braces, I don't share the concern that there is a risk of > somebody being confused when adding a second statement to a braceless > block. An actual risk is stuff like > > if (cond) > MACRO(argument); > > when MACRO expands to multiple statements. However, we should > accept that this is a bug in MACRO (which should have used the > do-while(0)-idiom), not in the application of the macro. > > Regards, > Martin > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com -- ಠ_ಠ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com