Method Chaining
Steven D'Aprano
steve at pearwood.info
Fri Jun 17 05:28:06 EDT 2016
On Fri, 17 Jun 2016 06:13 pm, Ned Batchelder wrote:
> To me, it's a toss-up. The chained version is nice in that it removes the
> repetition of "g". But the unchained version is more explicit, and avoids
> the awkward parenthesis.
>
> I think I would lean toward the unchained version. Clearly tastes can
> differ.
Indeed. For what it's worth, I'm ever-so-slightly leaning towards Lawrence's
taste here. What Michael Selik earlier described as advantages of the
explicit version:
g.move_to((p1 + p2a) / 2)
g.line_to(p1 + (p2 - p1) * frac)
g.line_to((p1 + p1a) / 2)
g.stroke()
namely, "no extra indentation, and no extraneous parentheses", is to me a
negative, not a positive. Since all these commands belong together in some
sense, I like the chained version:
(g.move_to((p1 + p2a) / 2)
.line_to(p1 + (p2 - p1) * frac)
.line_to((p1 + p1a) / 2)
.stroke()
)
as the parens and indentation more clearly mark this chunk of code as a
unit. On the other hand, I like the fact that methods which are
conceptually procedures that operate by side-effect return None. So it's
hard to decide precisely which behaviour is better. Its very much a matter
of taste.
--
Steven
More information about the Python-list
mailing list