Too much code - slicing

[Steven D'Aprano]

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.


> and the poll and discussion earlier made it
> clear that this was not the preferred way to have a ternary operator.

"Not preferred" != "ugly"


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


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


[...]
> It seems that what changed is your memory and not the collective mind of
> the python community.

Fair call.



-- 
Steven