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 -- https://mail.python.org/mailman/listinfo/python-list
