Too much code - slicing
steve-REMOVE-THIS at cybersource.com.au
Thu Sep 23 02:23:22 CEST 2010
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
> 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
> It seems that what changed is your memory and not the collective mind of
> the python community.
More information about the Python-list