----- Original Message -----
From: "Tim Peters"
It has much more to do with expectations for what "and" and "or" do. Note that they're not "operators" in Python, they're control structures, and cannot be overridden.
Yes, I realize what's actually going on (and/or are Lisp-y), but as I said, it rubs my expectations for expressions with bool the wrong way.
Don't mix bools with ints with control structures,
That mixing was your suggestion, if I recall <.02 wink>
and you won't get surprised; "False or 0" returning 0 in Python is no more surprising than that
if False: x = False else: x = 0
sets x to 0, and *oodles* of code relies on that equivalence.
I think you were the one who taught me the wonderful (x and [y] or [z])[0] trick, so yes, I'm aware of that. On the other hand (I hope I'm a flame-retard now), people shouldn't have to do stuff like that, especially in a world with bool. In any case, it seems to me that it's been correctly noted that you /will/ see these mixtures for quite some time to come, because of legacy code.
I think I'd better just write my own assertion routine, as Guido suggested. I don't like non-obvious language constructs for something so simple (I'd mention ?: here but I don't need the bruises).
Na, do this:
def bool(e): return e and 'True' or 'False'
Then wrap your true/false expressions in bool() calls. All assuming x-version invariance is important to you. When versions of Python before 2.3 become uninteresting, get rid of the bool() function (and so unmask the builtin of the same name).
Harrumph. The builtin doesn't create strings, but bools. I don't think doctest is going to ignore the quotes. -Dave