On Aug 31, 2016 7:22 PM, "Chris Kaynor" <ckaynor@zindagigames.com> wrote:
Guido's time machine strikes again,
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@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
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.) 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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@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/