[Python-ideas] Extending expressions using ellipsis

[Steven D'Aprano]

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