Too much code - slicing

Steven D'Aprano steve-REMOVE-THIS at
Thu Sep 23 02:33:28 CEST 2010

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> 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> 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


More information about the Python-list mailing list