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
--
http://mail.python.org/mailman/listinfo/python-list
