(PEP-308) Python's Conditional Selection Operators

[Gareth McCaughan]

Terry Reedy wrote:

>  <snip more useless quibbles about my usage of the word 'standard' in
>  one of its standard meanings  (recursive pun intentional)>
>  
>  To set the stage for my essay, I wrote: "Python's 'and' and 'or' are
>  not the standard versions:" and immediately explained the contrast
>  that I intended to explore and elucidate.
...
>  Please notice: I said 'In logic, math, and computing science...".  As
>  to logic and math, the rest of my statement is obviously correct.  As
>  for computing science, I am rather sure of correctness there also.
>  Two (nonrandom) examples: Knuth, AoCP 1, 2nd ed, p 346, "operators of
>  symbolic logic (AND, OR ..."); Gries, Sci of Prog. p9 "five operators
>  are defined over values of type *Boolean*: ... and ... or ...".  If
>  someone believe that these two prominent computer scientists are in
>  the minority, let them present some counter-evidence.

I agree that in mathematics (of which theoretical computer science
is a subdiscipline) the standard meanings of "and" and "or" are purely
boolean. However -- and doubtless to you this is a useless quibble --
what you said was not "Python's 'and' and 'or' are not the same as
those that are standard in logic, math and computer science", but
simply "Python's 'and' and 'or' are not the standard versions". It
seems to me that even when the following paragraph happens to be about
how they are used in one particular set of other contexts, it is
reasonable to read "not the standard versions" as saying something
more than "not the versions used in one particular set of other
contexts".

However, it appears that that's not what you meant, and I'm sorry
to have been among those who didn't correctly divine your meaning.

By the way, if you want to be as clear as possible that in "computer
science" you don't include "programming languages", you might want
to remove the words "and either conditional in execution or not",
or at least revise them. "Execution" is a term that applies to
computer programs, not to mathematical or logical expressions.

>  I intentionally did *not* add 'computer languages' to that list.  I
>  know that in C (and I presume C++) and/or are extended conditional
>  logic operators, but I don't know or have forgotten about most
>  everything else.

Actually, in C and C++ the <&&> and <||> operators (the nearest
equivalent to Python's <and> and <or>) are purely boolean. They
also have non-short-circuiting bitwise operators <&> and <|>, but
no one uses those for boolean operations other than by mistake.

>  Also, I wrote 'standard', not 'Standard' (as in ASCII, ANSI, ISO,
>  Standard C, etc).  Nor did I hint at the existence of any 'L, M, and
>  SC Terminology Standards Committee'.  I would prefer that people read,
>  study, and respond to what I did write rather than criticize what I
>  intentionally did not write.

I don't know whether that's referring to me, but my article was
a response to Stephen Horne, not to you. And what I said about
the ANSI standard in my reply to him was followed (1) by a smiley
and (2) by a clear acknowledgement that he didn't mean "standard"
in that sense.

> > The way it looks to me is:
> > Terry made a value judgement (objecting to Python's and/or
> > because they're "not the standard versions");
>  
>  Hogwash.  Read what I wrote and show me where I even *hint* at such an
>  objection (and I will revise it).  In point of fact, the person who
>  originally nitpicked 'standard' objects to what I write precisely
>  because I accept and use Python's definitions.

It seems that I misunderstood. Sorry about that. I think you "even *hint*
at such an objection" precisely by your use of the word "standard". Here's
an example of how you could have worded what you said so as not to confuse
useless quibblers like me.

    Python's "and" and "or" operators differ from those that may
    be familiar from mathematics, logic or theoretical computer
    science, or even from some other languages such as C and C++.
    In those domains, "and" and "or" are purely logical operations;
    they may perhaps accept non-boolean operands by some sort of
    conversion, and may "short-circuit" by not evaluating the
    second operand when the first suffices to determine the result,
    but they operate on boolean values (true and false), and return
    only boolean values.

    In Python, as in other dynamically typed languages like
    Perl and Smalltalk, these operations are generalized so
    that their results are not always boolean. I shall call
    them "conditional selection operators", and explain their
    unusual properties in the following sections.

(As it happens, I strongly dislike the term "conditional selection
operators"; <and>/<or> can be used that way, but calling them conditional
selection operators on those grounds is like calling <*> a boolean
operator on the grounds that if you feed it proper boolean values
it behaves like a non-short-circuiting <and>. But I digress.)

I'm not saying "You should replace your text with mine"; that would
be stupidly arrogant. My hope is that by comparing the two you'll get
a feeling for what it is in yours that led me to understand your
meaning and intent the way I did.

                              *

Anyway, Stephen's very wisely taken the discussion to e-mail; we can
flame one another about the merits and defects of Lisp there. :-) My
apologies for contributing to a language war in c.l.py .

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc