... 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>.