PEP 308: Alternative conditional operator forms -- Corner Case solved

[Dave Brueck]

On Wed, 12 Feb 2003, Terry Reedy wrote:

> "Dave Brueck" <dave at pythonapocrypha.com> wrote in message
> news:mailman.1045088213.3494.python-list at python.org...
> > Yes, I've been following that discussion too, but I'm in the camp
> that
> > says 'and' doesn't readily imply anything about choosing between two
> > things anyway,
>
> I have realized just today that at least some of the problem people
> have with the and/or combination arises from not having fully
> 'getting' Python's unusual definition of 'and' and 'or'.  In Python,
> they *are* conditional selection operators.

Or "getting it", but finding it so unintuitive that we avoid it as much as
possible - at least that's the category I fall into. I find

x = a and b

_barely_ tolerable, and just barely, but to be honest I don't really see
it in code much, if at all, especially compared to the simple

x = a or b

which is far more common, and anything more complex than a simple 'a and
b' is just unintelligible.

The 'x = a or b' doesn't cause me any problems because the context in
which I've seen it used is usually ensuring that some variable has a valid
value if what's expected doesn't happen, e.g.:

x = m.getName() or ''

(where getName is a method used in several places that returns None if the
name has not yet been set)

It's a small mental leap from 'or' as a purely logical operator to 'or',
in this context, as a selection operator - both behaviors have rather
strong parallels.

But with 'and' it's different (at least to me). In my mind it has nothing
to do with choosing between two things, so there's no reason for '5 and
""' to equal "", even though in Python it does. To me 'and' is very well
defined in logical operators, natural language, and even sets to mean
logical conjunction or intersection - how can the result of any of those
be one of the original components of the expression? I struggle to see the
parallel for it:

Joe: "I'm giving you a MILLION dollars and one dollar!"
Bob: "whoopee! I'm rich!"
[Job gives Bob one dollar]
Bob: "Hey!"
Joe: "PYTHON!!!!"

> They choose between alternatives presented as operands and only
> conditionally evaluate the second.  They only function as logical
> operators when *both* operands are logical values (0/1, False/True for
> Python).

Technically, yes, but often only because non-truth expressions are
implicitly converted to logical values. Despite whether or not it's bad
practice to assume non-None is true, people will always write:

if obj and obj.ready():
 ...

> Given this understanding (which I realize I should explain further),
> it is straightforward and obvious that their combination forms a
> conditional selection expression, just as the combination a+b*c forms
> an arithmetic expression.

Not quite: given the feeling that the base expression is unintelligible,
expanding upon it yields something even worse.

> >so I'm not keen on building on the current idiom at all.
>
> Given that you presented the view of 'and' behind your unkeenness, it
> it easier to understand.  I hope the reverse is true as well.

Yes, I certainly understand the reverse position: *if* 'and' as a
selection operator was intuitive to me, then building on it would be
elegant and have little negative impact (and 'a and b else c' would
probably be my choice). Unfortunately for me, that is not the case, but I
do understand where you're coming from.

-Dave