allowing braces around suites

[Michael Sparks]

On Sat, 28 Aug 2004, Kjetil Torgrim Homme wrote:

> after all, code in _any_ language written by a professional
> will have strict indentation.

Not all code is written by professional programmers. Not all professionals
who write code are professional programmers - biologists, linguists,
physicists spring to mind. Those groups are not interested in programming
they are interested in solving problems. They do not care about syntax,
they care about solutions. They care about sharing solutions.

Do you share solutions using pseudocode, or what you actually used? With
python you can do the latter, but it looks like the former. You can share
that with non-technical people - they might not understand the details,
but the lack of extraneous syntax will make this simpler, and they
appreciate being treated as equals.

For me, the lack of extraneous syntax and expecting the compiler to work
harder to leave code cleaner is one of the things that makes python
python. This actually means though that any tool that works with the
syntax needs to work a bit harder, but for me, the benefits are huge.

Contrast this approach with Perl's approach. (I really like perl as well
BTW) In perl there is explicit annotation of almost everything as to what
it means. You explicitly indicated scalars, arrays and hashes. If you need
to derefence an object the most reliable way is to use very explicit
syntax hooks. Similarly the braces are much more explicit than in a
language like C they aren't optional for block statements. If you want
_consistent_ semantics for all function calls, you have to use an & symbol
and so on.

This comes at cost however. The cost is that the large body of code
written by non-professionals can be difficult to read, merge and
encourages bad coding styles. (I've seen some very bad perl code from
people who claim to be professionals as well :-( )

I've yet to see this to the same extent with python. It very naturally
discourages bad coding styles whilst encouraging clean looking code -
including from new users. For me, this is part of what makes python
unique, and a large part of that in my eyes stems from making the work of
tools harder. Optional braces, AND keeping fixed indentation is simply
adding a crutch for poor tools.

The solution isn't to change the language in my eyes, the solution is to
produce better tools. After all, the following is legal syntax in python
if you really want close markers:

end = None
for ch in "hello":
   if ch == "l":
      print "Rhubarb"
   end
   print ch,
end

Personally I think that's like macro abuse in C where I've seen people try
to make C look like pascal, but it is valid - and it allows you to add a
crutch for your tools without changing the language or affecting
readability significantly.

All in my opinion of course. As has been said though - please do write the
PEP, I agree with the sentiment that this would be a good way of rejecting
it permenently ;-)

Best Regards,


Michael.