Too much code - slicing

[Antoon Pardon]

On Thu, Sep 23, 2010 at 12:23:22AM +0000, Steven D'Aprano wrote:
> On Tue, 21 Sep 2010 16:17:48 +0200, Antoon Pardon wrote:
> 
> > On Tue, Sep 21, 2010 at 12:07:07AM +0000, Steven D'Aprano wrote:
> >> On Mon, 20 Sep 2010 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