PEP-able? Expressional conditions

[Terry Hancock]

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.

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

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

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.

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

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.

Hence, I'm not big on discussing what sort of fake wings we can
glue onto it. It isn't that hard to live without a ternary operator.

You're just trying to program a C idiom in Python and cussing the
fact that it doesn't translate.  Sorry, loads of stuff doesn't, but
it doesn't necessarily make that a design flaw.

But if you really must avoid evaluating the results in your hand-crafted
ternary function, that is of course, also possible.  Go ahead and
write it and share it here, please.

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com