For review: PEP 308 - If-then-else expression

[Andrew Dalke]

David Eppstein:
> Turn it around a little and both versions become a little clearer:

Mmm, true if you follow nots.  I prefer not having nots because
it's harder for me to think backwards, especially since you
use both "in" and "not in"

> But really, the reason for the unreadability of all of these forms is
> that they make no sense -- they're built up of seemingly random strings
> with no obvious logical relation between the input and the output.

Ahh, I was trying to classify people in the Monty Python skit
as a decision tree.

There are three people, "vikings", "waitress" and "customer".

Q: How are they different?
A: The vikings and the waitress both like spam.
Q: Does the waitress like something the vikings do?
A: The vikings like eggs but the waitress does not.

Q: Okay, so if the person like spam, that person is either a
waitress or a viking, right?
A: Yes.
Q: And the waitress doesn't like eggs, right?
A: Yep.
Q: Okay, here's the Python code

  if "spam" in person.likes:
    if "eggs" in person.likes:
     role = "viking"
  else:
    role = "waitress"
else:
  role = "customer"
A: Hmmm, yep, looks good to me.

And that's how I came up with my expression.  It could
be done with a not, but that's not how the dialogue went.

> I think it makes more sense to judge this proposal by looking at real
> code that might use it, than by making up code-like pieces of poetry.

I did elsewhere.  I proposed this partially as a counter to
examples which were pro-if/else but also taken from overly
simple and likely infrequent cases.

                    Andrew
                    dalke at dalkescientific.com