[Info] PEP 308 accepted - new conditional expressions

[Dave Hansen]

On Mon, 10 Oct 2005 16:42:34 -0500, Terry Hancock
<hancock at anansispaceworks.com> wrote:

>On Sunday 09 October 2005 07:50 am, phil hunt wrote:
>> On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock <hancock at anansispaceworks.com> wrote:
>> >GvR's syntax has the advantage of making grammatical sense in English (i.e.
>> >reading it as written pretty much makes sense).
>> 
>> I know, let's re-write Python to make it more like COBOL! That's 
>> bound to be a winner!
>
>Whereas the "natural order" of "condition affirmative negative" is natural
>for what reason?  That it is so in C?

And Basic, and Fortran, and Lisp, and just about any programming
language you care to name, including python (if Condition: Affirmative
else: Negative).

Not to mention that the sequence is identical to execution order.
It's just plain goofy to have to scan to the middle of an expression
to find out what happens first, then depending on the result of that,
skipping back over what you just skipped.

>
>I don't find that so compelling either, frankly.  Why should it really
>matter in the end?  I've always found C's order (and punctuation) confusing,

Confusing how?  Perform test, choose branch.  Simple.

And it's not punctuation.  It's an operator, just like + or & or ~.  I
can understand how you might find the terseness confusing, though.

>I have to look it up practically everytime I use it or have to read it 
>(which correlates to it being used very rarely, with causality in both
>directions).

FWIW, in over 20 years of C programming, I use it pretty rarely too,
though I never had to look it up after I first saw it in K&R. It only
very rarely holds any advantage over a simple if/else statement,
especially in modern compilers. It's most useful in macros, which
python doesn't even have.

>
>Given that situation, choosing a form which is easy to read is surely
>an advantage, and, since it is the way that Python has handled logic
>in the past, it makes sense to continue doing so.

Easy to read out loud, but complex to understand, with all the back
and forth scanning required.

>
>No doubt, ANY choice of ternary operator for Python will be
>criticized, and no doubt, ANY choice would nevertheless be
>usable.

The whole idea of a ternary operator is somewhat complex.  

>
>OTOH, I think this choice is consistent with the rest of Python's
>design. The general choice to use keyword operators for LOGIC
>and symbolic operators for MATH is retained, and so long as we're
>describing the logic in words, it makes sense for the wording
>to sound natural.

I guess I agree, thoug I would have preferred to see something like
r = c ?then: yes else: no

>
>Consistency certainly does make it easier for me to remember.

I guess I disagree that it's consistent, at least with the way I see
python.

>
>Python's main advantage over other languages, for me, is that
>it makes me run to the manual a lot less, and I generally don't
>get confused trying to follow other people's code.

I'm inexperienced enough to keep Beazley's book at my elbow when
writing my own code, though reading other's code is usually simpler.
Until things like __metaclass__ and @classmethod start showing up...

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.