Tim Peters email@example.com wrote:
... 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'.
I understood the motivation for `repr(bool(1)) == "True"`.
What I wanted to say is that having repr return a readable result and str return a result looking like an internal representation runs counter to the usual conventions used for repr and str.
OTOH, I'm worried about backwards compatibility.
That's the only reason for str(True) to return '1'.
In this case, I'd value consistency between repr/str higher than backwards compatibility.
How about str(True) return '1' but str(False) return 'False'? That's what a committee would compromise on <wink>.
Any self respecting committee would try harder and probably come up with a really symmetric compromise:
value str repr True '1' 'True' False 'False' '0'
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".
Fine display of sophisticated hair splitting, but:
>>> class Foo: ... def __nonzero__(self): return None ... >>> f = Foo () >>> not f Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __nonzero__ should return an int >>>
I don't care about `should` vs. `must` as long as the new and improved Python won't spit an exception at __nonzero__ code returning an int instead of a bool.
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>.
Nice tease. But Guido's hammer with regard to future strictification of bool is exactly what makes me uneasy.