On Tue, 21 Sep 2010 12:26:29 -0400, Andreas Waldenburger wrote: > On Sat, 18 Sep 2010 19:09:33 -0700 (PDT) Carl Banks > <pavlovevide...@gmail.com> wrote: > >> On Sep 17, 1:01 pm, Andreas Waldenburger <use...@geekmail.invalid> >> wrote: >> > On Thu, 16 Sep 2010 16:20:33 -0400 AK <andrei....@gmail.com> wrote: >> > >> > > I also like this construct that works, I think, since 2.6: >> > >> > > code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] >> > >> > I wonder when this construct will finally start to look good. >> >> I don't know if it'll ever look good, per se, but it looks better when >> it's used in rule-exception sort of case: >> >> something = rule if condition else exception >> > Spot on. I (more or less) like it when used that way, too. But it seems > to invite crackers like the example above, and that irks me.
I don't see that one of these is more of a cracker than the other: code = if side == 'l' then dir[int(num):] else dir[:-1*int(num)] code = side == 'l' if dir[int(num):] else dir[:-1*int(num)] code = dir[int(num):] if side == 'l' else dir[:-1*int(num)] If you ask me, the *least* hard to read is the last. Unary and binary operators are natural in a language which is parsed in a single dimension (left-to-right in the case of English). There is no entirely natural way to parse a ternary operator, because you need to fit three operands into two slots. That's why mathematicians often use two dimensions when they need a ternary operator, like sum: ∞ ∑ expr i=0 -- Steven -- http://mail.python.org/mailman/listinfo/python-list