allowing braces around suites

[Jeff Shannon]

Kjetil Torgrim Homme wrote:

>[Jeff Shannon]:
>  
>
>>  The irony of [this] being said in defense of adding braces (even
>>  optional ones) to Python is truly awe-inspiring.
>>    
>>
>
>please provide an argument rather than engage in ad hominem attacks.
>  
>

One of the core concepts of Python philosophy is that of significant 
indentation being more reliable than braces to indicate program 
structure.  The whole point of using indentation is that it's far more 
natural for the human eye and mind to grasp; when one sees code in which 
braces and indentation are used, but inconsistently, the natural 
inclination is to follow the indentation rather than the braces.  The 
problem is that programmers have been trained for decades to use 
delimiters, because that's the way languages were designed, because 
earlier parsers had difficulty without them.  But programmers have 
*also* used indentation the whole time, because they needed it so that 
*they* could understand their own code.  The indentation is for the 
programmers, the braces are for the compiler.  Well, parser technology 
has advanced to the point where hints like braces aren't needed, but 
many programmers are so accustomed to having them that they keep looking 
for excuses to keep them around.

There are endless examples, as I said, of how inconsistently indented C 
code is far more confusing than braceless Python code.  Now, admittedly, 
your proposal here won't allow braces and indentation to be inconsistent 
-- that'll throw a syntax error.  But that means that you're encoding 
the same information in two ways, which is a waste of effort and a waste 
of mindspace.  This isn't just providing more than one way to do it; 
this is providing two ways to do it, and insisting that even if you use 
the second you need to *also* use the first.  That's like Amazon 
providing an online order form, but still insisting that you phone in 
your order before they'll deliver it.

Now, what do you gain by adding braces?  The ability of tools to better 
reindent code, supposedly.  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 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.

So... you're proposing a significant change to the core language syntax, 
which violates a number of Python core design principles, in order to 
simplify the process for a tool to perform an infrequent task, which 
it's quite capable of doing in a slightly different way already.  And 
yet, when someone else comments that the same lack-of-results can be 
accomplished with a currently legal (though pointless) bit of 
convention, you're worried that *they* are proposing something 
non-Pythonic?

Note, also, that this is not an ad hominem attack.  I say nothing about 
you personally -- my comments are based entirely on the proposal and 
argument that you put forward.  I'm not calling you names or questioning 
your morals; I'm merely pointing out that your complaint about Jacek's 
response can be applied far more aptly to your own original post.

Jeff Shannon
Technician/Programmer
Credit International

(PS: I'm going to be away from the newsgroup for the weekend, so lack of 
an immediate response on my part shouldn't be taken to construe anything 
significant...)