PEP 285: Adding a bool type

[Guido van Rossum]

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

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.

> because I meant "true/false expression" in the way Python has always
> meant it, e.g. operator.truth([]) == 0, but int([]) raises an
> exception.  The alternative int(bool(b)) is not obvious (else you
> would have thought of it first <wink>), and becomes needed only if
> operator.truth() is changed.

IMO, bool(x) is the right way to "normalize" any value into a truth
value.  The way I think of operator.truth(x) is as something returning
a normalized truth value.  Since we're changing all places that return
standard truth values from returning 0/1 to returning False/True, I
don't see why operator.truth() should not follow suit.  If we think
that we can change comparisons, isinstance(), s.islower() and so on to
return a bool without breaking much, I see no reason why we can't
change operator.truth().

> > Having to import the obscure 'operator' module for this purpose is
> > backwards.
> 
> Under the PEP it's extremely easy to get a bool result (bool(b)), so
> I favor presuming that anyone bothering to use operator.truth() will
> do so because bool() doesn't do what they want;

No, they do so because they wrote the code before bool existed.

> and if they're using truth() in 2.2, are doing so because they
> specifically want a 0/1 result.

And since False==0 and True==1, that's what they're getting.

I'm going to make this a BDFL pronouncement; I understand your
argument but I don't agree with it.

--Guido van Rossum (home page: http://www.python.org/~guido/)