On Sun, 31 Jul 2016 12:16 am, BartC wrote: > On 30/07/2016 14:06, Steven D'Aprano wrote: > >> End of story. As far as I am concerned, the 97% of languages which allow >> the visual structure of the code to differ from their logical structure >> are BAD LANGUAGES. > > You mean languages that allow code like this: > > a = ( > b > +c * > > > d) > > ?
Touché :-) But the layout of an expression is not really what I'm referring to. The whitespace between terms in an expression is meaningless. Yes, the example you give is particularly ugly, but it's no different from: a = ( b +c * d) on one line. Allowing parentheses to cross over line boundaries is a case of Practicality Over Purity: there are simply far too many cases where we want, *need*, a single expression to go over two or more lines, and the original solution (use a line continuation backslash) wasn't good enough. I'm referring to flow control elements (if...else, for, while, try...except, etc), plus a handful of other grouping elements (def, class, with). That's what I call "logical structure" of the code, not incidental whitespace between terms of a single expression. Unfortunately, there's sometimes a conflict between these disparate wants. I want the logical structure to be obvious; I want the freedom to arrange expressions over multiple lines. Sometimes they conflict, in which case, I do my best not to write ugly code. I'd be reluctant to prohibit expressions from starting at the left of the current indent: # This should always be allowed def func(): # current indent aligns here result = ( long expression over multiple lines ) return result # But this moves to the left of the current indent def func(): # current indent aligns here result = ( long expression over multiple lines ) return result I don't like that second case very much at all, but I wouldn't prohibit it, because I've found too many real world cases where I have big expressions (say, a table of values) where I need all the space I can get and need to visually outdent it without logically outdenting it. Its an ugly compromise between my otherwise very strict view, but that's life for you. > Another category is where code is written predominantly side-ways rather > than vertically. (Multiple chained method calls for example, or trying > to express something as a 'one-liner'.) I don't see the relevance. If you are writing a chain of method calls, its a single expression. There's no structure to express. As for one-liners, Python simply doesn't consider it important or necessary to support writing arbitrary one-liners. There's some limited support for the simple cases: python -c "for x in range(100): print(x**2)" but beyond that, you have to use multiple lines. -- Steven “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list