(original) (raw)

On 19.01.2016 00:20, Brett Cannon wrote:
\> On Sun, 17 Jan 2016 at 11:10 Brett Cannon <brett@python.org> wrote:
\>
\>> While doing a review of http://bugs.python.org/review/26129/ I asked to
\>> have curly braces put around all \`if\` statement bodies. Serhiy pointed out
\>> that PEP 7 says curly braces are optional:
\>> https://www.python.org/dev/peps/pep-0007/#id5. I would like to change
\>> that.
\>>
\>> My argument is to require them to prevent bugs like the one Apple made
\>> with OpenSSL about two years ago:
\>> https://www.imperialviolet.org/2014/02/22/applebug.html. Skipping the
\>> curly braces is purely an aesthetic thing while leaving them out can lead
\>> to actual bugs.
\>>
\>> Anyone object if I update PEP 7 to remove the optionality of curly braces
\>> in PEP 7?
\>>
\>
\> Currently this thread stands at:

Make that:

\> +1
\> Brett
\> Ethan
\> Robert
\> Georg
\> Nick
\> Maciej Szulik
\> +0
\> Guido
\> -0
\> Serhiy
> -1
MAL
> Victor (maybe; didn't specifically vote)
\> Larry
\> Stefan

There are plenty other cases where typos can ruin the flow
of your code in C; the discussed case is not a very common one.

I find the whole discussion a bit strange: In Python we're
advocating not having to use curly braces, because whitespace
already provides the needed semantics for us, yet you are
now advocating that without adding extra curly braces
we'd be in danger of writing wrong code.

The Apple bug can happen in Python just as well:

if a:
run\_if\_true()
else:
run\_if\_false()

can turn into (say by hitting a wrong key in the editor):

if a:
run\_if\_true()
run\_if\_false()

(run\_if\_false is now run when a is true, and nothing is
done in case a is false)

So what's the correct way to address this ?

It's having a test for both branches (a is true, a is false),
not starting to write e.g.

if a:
run\_if\_true()
if not a:
run\_if false()

to feel more "secure".

Also note that the extra braces won't necessarily help you.
If you remove "else" from:

if (a) {
run\_if\_true();
}
else {
run\_if\_false();
}

you get exactly the same Apply bug as before, only with more
curly braces.

This all sounds a bit like security theater to me ;-)

I'd say: people who feel better using the extra braces can use
them, while others who don't need them can go ahead as always
... and both groups should write more tests :-)

BTW: There are other things in PEP 7 which should probably be updated
instead, e.g. it still says we should use C89, but we're having more
and more C99 code (mostly new library functions) in CPython.

\--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 19 2016)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
\>>> Python Database Interfaces ... http://products.egenix.com/
\>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

::: We implement business ideas - efficiently in both time and costs :::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
http://www.malemburg.com/

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/soltysh%40gmail.com