Too much code - slicing
Antoon.Pardon at rece.vub.ac.be
Tue Sep 21 16:17:48 CEST 2010
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 and the poll and discussion earlier made it clear
that this was not the preferred way to have a ternary operator. 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
Nonsense. That the work around was buggy was known years before the
ternary operator was finally introduced. 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.
And we knew about the problem, that is why we discussed bug-free
condition and [true-expr] or [false-expr]
condition and (lambda: true-expr) or (lambda: false-expr)()
> The and-or hack, which was *very* common in Python code for many years
> and many versions, follows the same pattern as ternary if:
> true-clause if condition else false-clause
No it doesn't. the and-or-hack follows the same pattern as the if
condition, true clause, else clause
> It astounds me how the Python community changed it's collective mind from
> admiration of the elegance and simplicity of the expression when it was a
> buggy hack, to despising it when it became a bug-free language feature.
It seems that what changed is your memory and not the collective mind of
the python community.
We had an if statement and a (buggy) hack that followed the same pattern.
An earlier discussion and poll had revealed that people n general preferredr
to keep that pattern in a conditional expression. So why should you be
surprised when people express that they would have preferred a conditional
expression with a different pattern than we have now.
More information about the Python-list