PEP-able? Expressional conditions

[Antoon Pardon]

Op 2005-09-09, Terry Hancock schreef <hancock at anansispaceworks.com>:
> On Thursday 08 September 2005 04:30 am, Paul Rubin wrote:
>> Terry Hancock <hancock at anansispaceworks.com> writes:
>> > > Not the same at all.  It evaluates both the true and false results,
>> > > which may have side effects.
>> > 
>> > If you are depending on that kind of nit-picking behavior,
>> > you have a serious design flaw, a bug waiting to bite you,
>> > and code which shouldn't have been embedded in an expression
>> > in the first place.
>> 
>> Are you kidding?  Example (imagine a C-like ?: operator in Python):
>> 
>>    x = (i < len(a)) ? a[i] : None    # make sure i is in range
>>
>> Where's the design flaw? 
>
> It's a syntax error. See?
>
>>>> x = (i < len(a)) ? a[i] : None    # make sure i is in range
>   File "<stdin>", line 1
>     x = (i < len(a)) ? a[i] : None    # make sure i is in range
>                      ^
> SyntaxError: invalid syntax
>
> That's a pretty serious design flaw.
>
> You see, I'm not discussing an imaginary Python interpreter here.

Nobody is, but the general consensus about a ternary operator
has always been that it should have lazy evaluataion.
That is even mentioned in the PEP.
http://www.python.org/peps/pep-0308.html

    The BDFL's position is that short-circuit behavior is essential
    for an if-then-else construct to be added to the language.

And you did claim that depending on side effects was a serious design
flaw. And as far as I understand what you wrote that was independant
of the language used.


>> Where's the bug waiting to bite?  That's a
>> completely normal use of a conditional expression.  If the conditional
>> expression works correctly, this does the right thing, as intended.
>> If both results get evaluated, it throws a subscript out of range
>> error, not good.
>
> No. It throws a syntax error, as I demonstrated.

Which is a dishonest remark. The way you made the remark, made it
a claim about algorithmic design, independant of the language
chosen or the specific construct chosen to interpret it.

That Paul chose a construct that is not syntactic python to dispute
your claim, is beside the point.

>> Every time this topic comes up, the suggestions that get put forth are
>> far more confusing than just adding conditional expressions and being
>> done with it.
>
> If it's so easy, then do it, and quit whining. You could easily
> have published an alternative "better" ternary function instead
> of just complaining that mine "isn't right", by which you mean
> only that it doesn't work exactly as it would in C, or in your
> imaginary Python interpreter.

There have been alternatives enough that have been published.
It is not a matter of publishing yet an other alternative.
It is just that the BDFL has declare this a no no.

> Myself, I just can't see how writing:
>
> if (i < len(a)): x = a[i]
> else:		 x = None
>
> is gonna kill you.  It's also not by any means a solution so obvious
> that I would not want to see the special case on it's own line.

And how do I do this in a list comprehension?

Myself I couldn't see how writing:

  def fun(...):
     ...

  fun = deco(fun)

Would kill anyone, but decorator syntax appeared anyway.

> After all, in most cases where I would use a limiter like this, I'd
> want the special case to be handled by something other than None. Or
> I'd want to raise an exception, even.  Which, come to think of it,
> I wouldn't even have to code, would I?  The thing is, if you return
> None like this, you won't be able to treat it the same as the normal
> output, so you're still going to have to check the result. Which just
> means you've moved the complexity upwards  (almost always a bad move 
> which replicates effort -- another design flaw).

Examples given here, are done so to make a point. The example itself
may never been used in actual code, but code that is similar enough
in behaviour, may. Try to look at the argument one is trying to make
instead of looking at insignificant details.

> If you want to go and argue with Guido over this, go ahead. I'm all
> for a ternary operator.
>
> But IIRC, that parrot is dead. It's an ex-parrot.

Yes probably, but the fact that it is a dead parrot, doesn't make
the idea bad. I sometimes get the impression that just because
Guido declared a subject dead, some people feel obligated to
argue how bad it would have been anyway.

-- 
Antoon Pardon