PEP 285: Adding a bool type
Guido van Rossum
guido at python.org
Sat Mar 30 18:36:07 EST 2002
> [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/)
More information about the Python-list
mailing list