[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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4