On 2016-08-31 14:46, Shane Hathaway 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 sometimes write similar code with a sequence of pandas operations. I
think you can get a lot of mileage out of accepting the loss in precious
vertical space and just putting the closing parenthesis on its own line,
indented to the same level as the beginning of the line where the
corresponding open parenthesis was. Your example then becomes:
rows = (
dbsession.query(Table1)
.join(
Table2, Table2.y = Table1.y
)
.filter(Table1.x = xx)
.all()
)
This is essentially the way I write such code. This gives you most of
the important advantages you seek. You do need one extra set of
parentheses around the whole thing, but you never have to move or alter
those parentheses. You can freely add new lines (i.e., add the ".all()"
line if it wasn't there, as you suggested in a later post) without
interfering with existing lines. Moreover, some of the reasons you cite
in your later post for wanting indentation enforcement become less
important if you do things this way, because you are less likely to add
a parenthesis in the wrong place when your parentheses are clearly set
off like this. (It's true, though, that it might help even more if
Python would enforce the requirement that, when a line ends with an open
parenthesis, its counterpart must appear at the same indentation level.)
In my experience, the tradeoff between compactness and clarity is
rarely a major issue, because most expressions are either simple enough
that clarity is not at risk, or complex enough that compactness is not a
real benefit. If your expression is two or three lines long with no
long nested parentheses, it will probably be clear enough even if you
fudge a bit on the formatting. If your expression is ten lines long,
having to add an extra line or two (or even three) for closing
parentheses is not such a big deal. Basically, adding extra lines for
parentheses is only a pain if the expression was previously "short" and
now becomes "long", but not many expressions are very close to that
boundary.
All that said, I do think it is worth considering some syntax to make
this sort of thing easier. I'm not sure the Ellipsis approach is the
right one, but I'm interested to see where this thread goes.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
