Why can't I xor strings?
aleaxit at yahoo.com
Mon Oct 11 17:49:06 CEST 2004
Grant Edwards <grante at visi.com> wrote:
> On 2004-10-11, Alex Martelli <aleaxit at yahoo.com> wrote:
> >> Surely they must coerce the operands for the "test" part if not
> >> for the "return" part.
> > We may have different conceptions about the meaning of the word
> > "coerce", perhaps...? For example, Python may be doing len(x) when I
> > use x in a boolean context,
> I guess I was assuming Python was doing the equivalent of
> bool(x) when x was used as an operand of a logical operator.
> That's coercion to me.
Well, Python is doing just the same thing it was doing before 'bool' was
introduced (in 2.2.1, I think) -- Truth Value Testing. I believe a very
similar transition happened, for example, in the C++ language: any
number or pointer was and still is acceptable in a "condition" context
(e.g., for C, 'if(x) ...'). That used to be quite different from
coercions. Then a 'bool' type was introduced -- the language still kept
doing exactly the same thing for 'if(x)' and the like, but even though
nothing was changed, it ``feels'' taxonomically different (in C++ the
case is stronger, because a new 'operator bool' was also introduced; and
with it new and important pitfalls, cfr
> > but I sure don't see computing len(x) as "coercing" anything.
> > To me, Coercion, in Python, is what's documented at
> > <http://docs.python.org/ref/coercion-rules.html> and is quite
> > a different concept from Truth Value Testing, which is
> > documented at <http://docs.python.org/lib/truth.html>.
> I guess I'm misusing the term coercion (at least in a Python
> context). To _me_ operands of logical operators are being
> coerced to boolean.
Didactically, I still prefer to say they're "being truth-value tested",
because the concept of a hypothetical coercion which happens during the
testing then "un-happens" to determine the result is just impossible to
get across -- even if I thought it somehow more correct or preferable,
which I don't. Note, again, that in C++ the case to consider
truth-value testing as coercion is stronger, because && and ||
(shortcircuiting logical operators) _DO_ undertake to always return a
bool, when applied to C++'s built-in types. I consider this a
suboptimal decision, prompting people to code 'x?x:y' or 'x?y:x' where
they might have coded, more simply, x||y or x&&y respectively, were it
not for the coercion which the latter forms imply.
BTW, if you consider a form such as 'x?x:y', which is a better match for
the semantics of Python's 'x or y' than C++'s || operator, you will see
why speaking of operandS (plural) as being 'coerced' is surely
misleading. Under _no_ conceivable circumstances is the RHS operand
subject to any operation whatsoever by 'x or y'. Whatever "coercion"
is, it definitely cannot be happening here on y. Similarly for the
analogous 'x and y' -- never is any operation at all done on y.
Truth Value Testing (which you want to call coercion) happens on the
first (LHS) operand, but not on the second (RHS) one, ever...
More information about the Python-list