Too much code - slicing
usenot at geekmail.INVALID
Thu Sep 23 17:40:55 CEST 2010
On 23 Sep 2010 00:33:28 GMT Steven D'Aprano
<steve-REMOVE-THIS at 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
> > <pavlovevidence at gmail.com> wrote:
> >> On Sep 17, 1:01 pm, Andreas Waldenburger <use... at geekmail.INVALID>
> >> wrote:
> >> > On Thu, 16 Sep 2010 16:20:33 -0400 AK <andrei.... at 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.
More information about the Python-list