On Wed, Aug 31, 2016 at 03:46:13PM -0600, Shane Hathaway wrote:
Cons:
- Extra parentheses are required.
You have to have extra *something* no matter how you do it. An extra semi-colon at the end of the statement, in semi-colon language. An extra backslash at the end of the line. An extra pair of parens. I don't see this as a meaningful negative.
- The indentation is not enforced by the parser, so I have unnecessary freedom that could let various mistakes slip through.
I don't see how. Its precisely because the indentation is not enforced that you *can't* get errors related to the indentation. Of course you can still get other errors, like dropping a comma between function arguments, or failing to close a pair of brackets, but enforcing indentation doesn't protect you against those. Can you demonstrate an error that can be prevented by enforcing indentation inside an expression? In fact, can you explain what indentation rules you want to enforce? Its not clear to me exactly what you want.
- The closing parenthesis has to move every time I append to or reorder the expression, leading to diff noise in version control. (Alternatively, I could put the closing parenthesis on its own line, but that consumes precious vertical reading space.)
I don't get this argument either. There are two situations: you have the closing paren just after the final token, or you have it on a line of its own. If its on a line of its own, you don't need to change it if you modify the expression (as you state yourself). But if its on the same line as the final token, and you modify that line by appending or re-ordering, there's going to be a diff regardless: result = ( blah blah blah blah blah blah blah + x - y or spam.eggs()) becomes: result = ( blah blah blah blah blah x - y blah blah or spam.eggs() or default) The presence or absence of that outermost pair of brackets doesn't affect the diff in any way. You either change the line, and get a diff, or you don't, and don't. At least that's how I see it. Can you show the sort of diff noise that you're talking about?
I'd like to suggest a small change to the Python parser that would make long expressions read better:
rows = dbsession.query(Table1) ... .join( Table2, Table2.y = Table1.y) .filter(Table1.x = xx) .all()
The idea is to use an ellipsis at the end of a line to spread an expression over multiple indented lines, terminated by a return to an earlier indentation level. You can still indent more deeply as needed, as shown above by the join() method call.
Three dots is already syntax for Ellipsis, so this is going to be ambiguous. There will be expressions where ... is valid, and the parser cannot tell if it is intended as a line continuation or not. result = spam + ... (eggs or cheese)(arg) Is that a line continuation, or an accidentally indented line which ought to raise a SyntaxError?
This syntax has all the pros of the existing syntax and resolves all the cons:
I'm not convinced that any of your "cons" actually are cons. See my questions above.
- No extra parentheses are required.
So instead of two extra characters, you need three extra characters. I'm not seeing how this is a benefit.
- The indentation is enforced, so my mistakes are more likely to be caught early. - Without a closing parenthesis, there is no diff noise when I append to or reorder an expression.
As above, I'm not seeing how this is supposed to work. -- Steve