Terry Reedy wrote:
> During the c.l.p debate, someone counted about 100 correct uses of 'a and b
> or c' in the standard library. But one real misuse edged Guido toward
> replacing it. So I think the replacement should be as clear as reasonably
> possible and clearly an improvement.
But I think there's a difference in kind here - to *fix* Raymond's example
required a fundamental change to the structure of the line, none of which
looked as clean as the original. There is no way to get the and/or construct
to gracefully handle the case where the desired result in the 'true' case
might itself be false: either you change to using an if statement, or you use
a workaround like the ugly singleton-list approach.
That is, the following is fundamentally broken for pure imaginary numbers:
return isinstance(z, ComplexType) and z.real or z
Fixing it requires changing to either:
return (isinstance(z, ComplexType) and [z.real] or [z])[0]
or:
if isinstance(z, ComplexType)
return z.real
else:
return z
This is not the case with an in-fix notation for conditional expressions - you
can fix a broken line simply by moving the relevant expressions to the correct
locations.
return isinstance(z, ComplexType) if z.real else z # Broken!
return z.real if isinstance(z, ComplexType) else z # Correct!
I see this as being in the same category of error as writing "return foo **
baz" when you really should have written "return baz ** foo" (i.e., not the
language's problem). (Random aside: it would be nice if "foo ** bar % baz"
automatically invoked the three argument form of 'pow')
> Now, can you honestly say that you would (naively) read
>
> return foo if bar else baz
>
> and be certain you knew what it meant?
Yes. I'd expect it to read like English - "Return foo if bar is true,
otherwise return baz". Whether that was was what code was *supposed* to be
doing, I couldn't assess without additional context (but that is true
regardless of the syntax).
With the prefix notation used for C's conditional operator, I simply don't
read it in the order it's written - I read "return bar ? foo : baz" as "if bar
is true then return foo, otherwise return baz". That's possible with C because
it uses punctuation - using an English keyword instead makes it significantly
harder for me to consider interpreting the construct that way (In fact, the
only way I can get my brain to accept it is by mentally replacing the "if"
with "?" and the "else" with ":").
Does it help if you think of "if <C> else" as a parameterised infix operation
for choosing between the expressions on either side?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
