> The effort required to do this is not the argument, > it's the fact that you are trying to break working code > without any real life need. The PEP doesn't mention a > single example where the advantage is so obvious that > it requires breaking code. OK, now we're talking. You want more motivation. See my response to David Ascher; I'm going to add all that to the PEP online too. > > > I'd be happy with repr(True) giving me 'True', > > > but not str(True). > > > > It just seems to make more sense if booleans print as True and False. > > But if that really is going to be the only place where things break, > > I'm willing to reconsider this. > > Good. This is now in the PEP as an option. > The problem is that the boolean output may not have been > intended by the programmer. All he ever got was the integers > 1 and 0 -- it was never obvious to the pure Python programmer > that these two values were acutally the singletons > Py_True and Py_False. Now you want to add additional > semantics to those and things will look different on output. In the long run, you'll thank me for this. --Guido van Rossum (home page: http://www.python.org/~guido/)
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