Too much code - slicing

[Steven D'Aprano]

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.

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