(original) (raw)

On Tue, 19 Jan 2016 at 19:33 Martin Panter <vadmium+py@gmail.com> wrote:

On 19 January 2016 at 20:12, Brett Cannon <brett@python.org> wrote:
\> Here is a proposed update:
\>
\> diff -r 633f51d10a67 pep-0007.txt
\> --- a/pep-0007.txt Mon Jan 18 10:52:57 2016 -0800
\> +++ b/pep-0007.txt Tue Jan 19 12:11:44 2016 -0800
\> @@ -75,9 +75,9 @@
\> }
\>
\> \* Code structure: one space between keywords like \`\`if\`\`, \`\`for\`\` and
\> - the following left paren; no spaces inside the paren; braces may be
\> - omitted where C permits but when present, they should be formatted
\> - as shown::
\> + the following left paren; no spaces inside the paren; braces are
\> + strongly preferred but may be omitted where C permits, and they
\> + should be formatted as shown::
\>
\> if (mro != NULL) {
\> ...

This change seems to be accidentally smuggled in, in the guise of a
PEP 512 update :)

Darn, sorry about that; forgot I had that change sitting in my peps checkout. I'll revert it when I get home (unless the change is actually acceptable to Guido).

-Brett

My view is I prefer always using curly brackets in my own code. It is
easier to add printf() debugging without making mistakes. I support
“strongly preferring” them in the style guide, which is as much as a
style guide can do anyway.