PEP 285: Adding a bool type

[Tim Peters]

[Guido, on why operator.truth() should change to return True/False]
>>> Tim must be missing something.  The obvious way to turn a bool b into
>>> an int is int(b).

[Tim, being difficult]
>> It's also an incorrect way for me,

[Guido, being more difficult]
> No it's not, note that I said "turn a bool b into an int".  Clearly
> the assumption there is that b is a bool, not an arbitrary value in
> whose truth value we're interested.

In context, your original int(b) suggestion was in response to my:

    people have a legitimate need to make an arbitrary true/false
    expression produce 0 and 1 too, if only to preserve 0/1-based
    true/false output.  operator.truth() has always been the best
    way to do exactly that.  Alternatives like "(boolexpr) + 0" and
    "(boolexpr) and 1 or 0" and "(0,1)[boolexpr]" reek in comparison.

where, as I explained in the later msg to which you're replying now, just in
case it wasn't clear the first time around:

    I meant "true/false expression" in the way Python has always
    meant it, e.g. operator.truth([]) == 0, but int([]) raises an
    exception.

So you may say that "clearly the assumption there is that b is a bool", but
it's not at all clear that was a *reasonable* assumption in the context in
which you first said it:  I've been thru the business twice now of
explaining why int() isn't suitable for the cases I was talking about.
int(bool) is not a case I was talking about.

> IMO, bool(x) is the right way to "normalize" any value into a truth
> value.

Sure, it will be.  But if you need to, e.g., "preserve 0/1-based true/false
output", bool(x) may not work (depending on whether you yield to making
str(bool) and/or repr(bool) return "0"/"1").

> The way I think of operator.truth(x) is as something returning
> a normalized truth value.

Well, that's where we differ:  bool(x) will be *the* "right way to
'normalize' any value into a truth value".  As at the start, I don't need
two "right ways" to do exactly the same thing.

> ...
> [more of the same]
> ...
> I'm going to make this a BDFL pronouncement; I understand your
> argument but I don't agree with it.

Whew!  I'm glad that's finally over,

you-should-do-that-more-often<wink>-ly y'rs  - tim