[Python-ideas] Extending expressions using ellipsis

[Ryan Gonzalez]

On Aug 31, 2016 7:22 PM, "Chris Kaynor" <ckaynor at zindagigames.com> wrote:
>
> Guido's time machine strikes again,

GAH! We should've just used that for PEPs 484 and 526; instead of trying to
prove type hints are useful, Guido could've just:

1. Go 50 years into the future.
2. Make note of the Python's world domination (Perl is overrated).
3. Grab random examples of code using type hints and note that no nuclear
missile switches have gone off like last time\b\b\b\b\b\b\b\b\b\b has never
happened.
4. Bring them back here and shove it in the rationale.

Problem solved! (Unless of course, the time machine accidentally sets off
one of those missile switches like last time\b\b\b\b\b\b\b\b\b\b has never
happened.)

> though using a slash (\) rather than elipse:
>
> >>> '.'\
> ... .join(
> ...     (
> ...             '1',
> ...             '2',
> ...     )
> ... )
> '1.2'
>
> This is from Python 2.7.10 (what I have on the machine I am currently
on), though I'm fairly sure it has worked for quite a bit longer than that.
>
> Chris
>
> On Wed, Aug 31, 2016 at 2:46 PM, Shane Hathaway <shane at hathawaymix.org>
wrote:
>>
>> Hi,
>>
>> I write a lot of SQLAlchemy code that looks more or less like this:
>>
>> rows = (
>>     dbsession.query(Table1)
>>     .join(
>>         Table2, Table2.y = Table1.y)
>>     .filter(Table1.x = xx)
>>     .all())
>>
>> The expressions get very long and nearly always need to be spread to
multiple lines. I've tried various styles and have chosen the style above
as the most tasteful available.
>>
>> Pros of the existing syntax:
>>
>> - It's possible to indent clearly and consistently.
>> - Nested indentation works out OK.
>> - It's flexible; I can combine lines or separate them for emphasis.
>>
>> Cons:
>>
>> - Extra parentheses are required.
>> - The indentation is not enforced by the parser, so I have unnecessary
freedom that could let various mistakes slip through.
>> - 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'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.
>>
>> This syntax has all the pros of the existing syntax and resolves all the
cons:
>>
>> - No extra parentheses are required.
>> - 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.
>>
>> I've thought about using a colon instead of an ellipsis, but in Python,
a colon starts a list of statements; that's not my goal. Instead, I'm
looking for ways to use parser-enforced indentation to avoid mistakes and
help my code read better without changing any semantics.
>>
>> Feedback is welcome!
>>
>> Shane
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160831/b5158221/attachment.html>