9 ms·
And does that remove the need for parentheses? ;) Because actually, it gets more complicated than that. Sometimes it makes more sense to say: def open_wind
by euccastro 16y ago
And does that remove the need for parentheses? ;)
Because actually, it gets more complicated than that. Sometimes it makes more sense to say:
def open_window(x, y
width, height,
resizable=True,
caption="")
Without parens, is x, y a tuple or two separate arguments? And do I want to remember that?
Also, what's inside the parens could have been a generator expression, which could have been conceivably partitioned in more than one sensible way, and which could have subexpressions with parens or brackets itself.
Sounds contrived? I do it all the time and it often looks and reads just fine.
I'm not arguing against your indentation rule, which is the one I use, and not even against the proposal of making it mandatory (although I'm not sure that in the heat of refactoring I'd appreciate the unnecessary SyntaxErrors), but about the point that making it mandatory would make parens unnecessary.
- Locke1689 16y agoTrue, although Haskell does show we can do function application without excessive parentheses. I think you're definitely right about Python, though. Fundamentally, Python is still a procedural, block style language. If it were written in the same functional style as Lisp it would probably be just as complex.
- silentbicycle 16y agoThe ML and APL families also do function application without excessive parens. I don't think Lisp's grouping rules are complex. There are a few functions with special grouping, particularly let and cond, but anybody doing real programming in Lisp gets used to them pretty quickly. (Lisp is hardly the only language with special cases in its syntax!) User-added functions seldom have elaborate nesting schemes, or at least have a damned good reason.