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