Too much code - slicing

Mon Sep 27 07:07:49 EDT 2010

On Thu, Sep 23, 2010 at 12:23:22AM +0000, Steven D'Aprano wrote:
> On 2010年9月21日 16:17:48 +0200, Antoon Pardon wrote:
>> > On Tue, Sep 21, 2010 at 12:07:07AM +0000, Steven D'Aprano wrote:
> >> On 2010年9月20日 19:28:49 +0200, Antoon Pardon wrote:
> >> 
> >> > Not necessarily. Some of us have the impression that Guido
> >> > deliberatly chose an ugly format for the ternary operator.
> >> 
> >> If he did, then he must have changed his mind, because there is nothing
> >> ugly about the ternary operator we ended up with.
> > 
> > That is a question of taste 
>> Yes, it certainly is. Describing it as "an ugly format" is also a matter 
> of taste -- taste which in my opinion simply isn't justified by anything 
> other than familiarity.

There is the facts that it broke familiarity with a common pattern.
> > This form only ranked fourth (or maybe third), with the first three all
> > wanting ar structure with the elelement is this order: condition, true
> > case, false case
> > 
> >> > Guido has alwasys been
> >> > against a ternary operator but the requests kept coming. So
> >> > eventually he introduced one. But the impression is that he chose an
> >> > ugly format in the hope of discouraging people to use it.
> >> 
> >> That's sheer and unadulterated nonsense. The fact is that Guido changed
> >> his mind about ternary if after discovering that the work-around
> >> 
> >> true-clause and condition or false-clause
> >> 
> >> is buggy -- it gives the wrong answer if true-clause happens to be a
> >> false value like [], 0 or None. If I recall correctly, the bug bit
> >> Guido himself.
> > 
> > Nonsense. That the work around was buggy was known years before the
> > ternary operator was finally introduced.
>> But people kept forgetting it, and it bit the right person one time too 
> many.

So? That it took years between the knowledge that the work-around failed
and a ternary operator finally appearing is still a fact. Which casts doubts
that is was this knowledge that made him change his mind.
> > The introduction of list
> > comprehension made a ternary operator that more usefull but every time
> > it came up the supporters of Guido, told us we just had to define a
> > function if we wanted the items to depend on a condition.
>> A function can't do the job, because it isn't lazy:
>> def ifte(condition, x, y):
> if condition: return x
> else: return y
>> n = 0
> ifte(n != 0, 100/n, -1)
>> will fail. This was perhaps *the* killer argument for a ternary-if 
> operator.

You really don't seem to remember what happened then.
Someone would come with a problem that we can now solve as follows.
ls = [ el / 2 if el % 2 == 0 else 3 * el + 1 for el in ls ]
and the respons would be that we just needed to write is as follows:
def f(el):
 if el % 2 == 0:
 return el / 2
 else:
 return 3 * el + 1
ls = [ f(el) for el in ls ]
-- 
Antoon Pardon