allowing braces around suites

Kjetil Torgrim Homme kjetilho at
Sat Aug 28 11:47:31 CEST 2004

[Jeff Shannon]:
>   Now, what do you gain by adding braces?  The ability of tools to
>   better reindent code, supposedly.

no, the ability of having wrongly indented code throw syntax errors.
there are many workarounds for individual editors, but nothing to help
eliminate this error class altogether.

the many workarounds also lead to "more than one way to do it".  the
code I read can be using "#fi", "# end if", "# }", "pass" or nothing.
sure, I can write a tool to enforce a single coding standard for my
project, but external code will naturally not comply.  that's why I
think it would be good if Python decreed a single method of using both
belts and braces.

currently, I'm using the "nothing" style, and like it very much.  my
motivation is that a member of our development group religuously
litters his code with "#fi" and "#done".  rather than just tell him to
stop it, I thought I'd explore the avenue of a compromise, since I
myself would like to use braces in my code in some instances to
improve the visual cue in "deep" (4-5) indentation blocks.  (this can
happen even if the function fits on the screen.  splitting out the
core of it is in some cases awkward.)

>   But I have to say, using block-indent and block-dedent commands,
>   I've never had a difficult time with maintaining proper relative
>   indentation of cut-and-pasted code blocks.

I wouldn't say it's a frequent problem for me, it's happening me a
couple of times per year, and some of my colleagues report likewise.
but wasting perhaps a workday a year on such a silly issue is

>   I don't see the problem you're trying to solve, I'm not aware of
>   it being a significant problem throughout Python's 10+ year
>   history, and I honestly doubt that your "solution" would provide
>   much significant benefit.

my hope is that my solution can be ignored by those who don't need it,
and used by those who like it.

>   Note, also, that this is not an ad hominem attack.

no, it was a long, well thought-out article.  thank you.
Kjetil T.

More information about the Python-list mailing list