Why can't I xor strings?

[Alex Martelli]

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, 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>.


Alex

 

[Brian Quinlan]

Surely they must coerce the operands for the "test" part if not
for the "return" part.

Is calling a method cosidered coercing? The "test" part must call the
object's __nonzero__ method but no Python boolean object is ever created.

Cheers,
Brian

 

[Grant Edwards]

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.

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.

 

[Alex Martelli]

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
<http://www.artima.com/cppsource/safebool.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...


Alex

 

[Jeremy Bowers]

That's news to me. I've used three different base-2
representations for negative numbers in the past week, and I
can think of at least one other one I've used in the past.

I am aware of only one encoding that uses a single bit to represent sign,
as I stipulated, and discarding endianness issues I'm having a hard time
imagining what reasonable alternatives there are.

That depends on which base-2 representation you've chosen. In
two's compiliment and excess-N representations, there is only
one zero value. In signed-magnitude there may be two.

I explicitly only discussed signed-magnitude: "Assuming an extra bit to
show sign".

Normally I'd exhort you to read more carefully but Bengt pointed out some
places I wasn't rigorous with my terms. So I earned this.

 

[Grant Edwards]

I am aware of only one encoding that uses a single bit to
represent sign, as I stipulated, and discarding endianness
issues I'm having a hard time imagining what reasonable
alternatives there are.

* Two's compliment.
* One's compliment.
* Signed-magnitude with a "1" sign bit being positive.
* Signed-magnitude with a "1" sign bit being negative.
* Excess-N notation.

Four of the five are in use in the software I'm working on
today.

I explicitly only discussed signed-magnitude: "Assuming an
extra bit to show sign".

I don't know what you mean. Two's compliment, one's
compliment, signed-magnitude, and excess-N _all_ use a single
bit for sign.

 

[Jeremy Bowers]

I don't know what you mean. Two's compliment, one's
compliment, signed-magnitude, and excess-N _all_ use a single
bit for sign.

I meant a single bit exclusively for sign, such that

1 00001001

and

0 00001001

are the same absolute value. The complements don't work that way. I
guess that does leave a question for whether 1 is positive or negative,
but for the purposes of my point, that doesn't matter much.

 

[Grant Edwards]

I meant a single bit exclusively for sign, such that

1 00001001

and

0 00001001

are the same absolute value. The complements don't work that
way. I guess that does leave a question for whether 1 is
positive or negative, but for the purposes of my point, that
doesn't matter much.

OK, if you meant signed-magnitude, you should have said that.

AFAICT, the only people that use signed-magnitude for _integer_
quantities [IEEE FP representations are signed-magnitude] are
the analog guys who design A/D converters [and somebody needs
to slap them and tell them that out in the real world we want
2's compliment].

I haven't _ever_ seen a signed-magnitude integer ALU, but I'm
sure some existed back before I started doing this sort of
stuff 25 years ago.

 

[Jeremy Bowers]

OK, if you meant signed-magnitude, you should have said that.

AFAICT, the only people that use signed-magnitude for _integer_
quantities [IEEE FP representations are signed-magnitude] are

I never said they existed

 

[Andr? Roberge]

I suggest you have a look at the following:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/252237

I believe it does what you want (and has little to do with the
follow-up discussion so far!)

Andre Roberge

 

[Andrew Dalke]

Alex

str1 != str2 and (str1+str2) == (str2+str1)

I guess I'd better stop here because I can't actually _prove_ the last
one of these actually implies one of the strings is empty but I can't
find counterexamples either...!-)

str1 = "a"
str2 = "aa"

Andrew
(e-mail address removed)