On 23 Sep 2010 00:33:28 GMT Steven D'Aprano <steve-remove-t...@cybersource.com.au> wrote:
> 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. > I agree again. I wasn't really talking about the specific order of the ternary operator but rather about the whole idea. It invites messiness. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list