On Fri, Nov 12, 2010 at 03:27:15AM +0800, C. Scott Ananian wrote: > On Fri, Nov 12, 2010 at 2:09 AM, Simon Schampijer <si...@schampijer.de> > wrote: > > In general I would do what the spec says if there is no good reason not to > > [1]. The example they have does not really handle all the cases, though. > > Neither pep8 nor pylint does favor any formatting. So I guess we are a bit > > free here. > > I belive PEP8's example is rather definitive: > > "... Make sure to indent the continued line appropriately. The preferred > place to break around a binary operator is *after* the operator, not before > it.[" ...] > I don't think there's any ambiguity there, actually.
Indeed, so I think we should accept that: it's written down that way and the issue is otherwise open to legitimate argument (I think it's a overly prescriptive, though[1]). > --scott Martin [1] When the boolean logic joining the tests are quite important relative to the tests themselves, the boolean operators benefit from emphasis: if (width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight > 100): ...rather than: if (width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight > 100): But we can argue about this point for a while. That example really sucks, since it uses implicit precedence in ways that are quite liable to require people to refer to the documentation[2]: if w and h and c and e or hi: ...if I saw that in code I'd want it changed to: if (w and h and c and e) or hi: ...which is what it means, not: if w and h and c and (e or hi): I had to convince myself: w = False h = True c = True e = True hi = True print w and h and c and e or hi print (w and h and c and e) or hi print w and h and c and (e or hi) ...yields: True True False [2] http://docs.python.org/reference/expressions.html#summary
pgpv8aqtmB41F.pgp
Description: PGP signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel