Home Original page

allow line break at operators

Ethan Furman ethan at stoneleaf.us
Thu Aug 11 18:43:39 EDT 2011 
Seebs wrote:
>> We're fully aware of the tradeoffs of significant indentation.
> 
> You are.  A couple of other people I've talked to are.  Many others
> are not.

The times that whitespace indentation has bitten me, it was still not 
difficult to fix -- I just had to look and see which line(s) 
should/should not be where they were.


>> Because people simply don't like it when their code's indentation doesn't
>> match the actual semantics, people usually manually ensure that the two
>> match, braces or no braces. Editors still have commands to indent and
>> outdent blocks of code. There is no difference between (say) C or Pascal
>> and Python in that regard.
> 
> Yes, there very much is.
> 
> You can't outdent "a block" in Python unless it is already correctly
> indented.

I fix the block, then move it as I need to.


> The underlying thing I've noticed is:
> 
> Braces have problems more often, but the problems are *always* 100%
> machine-fixable and therefore trivial.  It takes milliseconds to get
> a program fixed so it looks like what it means.

Not so.  If the braces do not match /intent/ (which is the problem I 
care most about) then it cannot be fixed by machine.

> Indentation has problems less often, but the problems are *never*
> machine-fixable.  It takes minutes or hours to figure out what was
> supposed to be there.

I can see where a messed-up mail server could cause hours of grief.  Not 
having experienced that, but only cases where I, myself, accidently 
changed indentation when I should have, it's not been a big deal to fix; 
I'm willing to live with not having the machine reformat my source code 
from incorrect to correct.

...

> Well, seriously.  If I could, I would.  If it were up to me, I'd talk to the
> people who'd picked Python for some stuff I have to work for, point out the
> hostility of the Python community to newcomers whose workflows don't happen
> to have been preemptively built entirely around Python's design decisions,
> and suggest that maybe we use another language.  Heck, since I've been
> encouraged so much to do so, I think I will.

Your choice, obviously -- seems a shame to me, though, to give up on 
Python because of one or two ouchy areas on c.l.py.  By and large it's a 
very helpful and courteous community.

~Ethan~
More information about the Python-list mailing list