PEP 285: Adding a bool type

[Tim Peters]

[Christian Tanzer]
> ...
> If str and repr were to behave differently from each other, I'd expect
> repr(True) to return "1" and str(True) to return "True". Interchanging
> that seems strange.

We try to ensure that eval(repr(x)) reproduce x whenever reasonably
possible.  That best way to do that here is for repr(True) to return 'True'.
We also try to ensure that str(x) be "friendly" whenever possible, even if
that means eval(str(x)) has no chance of reproducing x exactly, or even of
running without raising an exception.  The best way to do that here is also
for str(True) to return 'True', but:

> OTOH, I'm worried about backwards compatibility.

That's the only reason for str(True) to return '1'.  How about str(True)
return '1' but str(False) return 'False'?  That's what a committee would
compromise on <wink>.

> ...
> How will bool influence '__nonzero__'? Currently, Python insists that
> '__nonzero__ should return an int'. Will this be changed to 'should
> return a bool'?

I hope so.

> As that would break existing code, I hope not.

No, "should" != "must".  Guido won't call code that returns an int here
broken, although he might call it deprecated, and leave you wondering when
the hammer will drop <wink>.