> > But this is the whole point of introducing a new type rather than > > simply defining True as 1 and False as 0! > > That's not how I read it: making bool a type would allow type > checks to be done and this is a *much* more important feature > to have than some different str(obj) output. Depending on your POV, yes. > There are many situations when doing RPC or interfacing with > other systems such as databases where a type check for > booleans is needed. Agreed, this is a nice additional advantage. > Currently, this can be done by simply using the already > existing Py_True and Py_False which are exposed at > Python level through (1==1) and (1==0) and we should not > break this scheme. '%s' % True must continue to > deliver '0' otherwise you'll end up breaking interfaces > which rely on this (such as database modules). That's a good question. Don't databases have a separate Boolean type? Is there really code out that relies on this? The code would have to assume that the boolean argument is already normalized to being exactly 0 or 1; a generalized Python truth value wouldn't work. I can provide a real implementation next week, and we should have plenty of time to find out how much it breaks. > There's also another issue here: "True" and "False" > are English words, "0" and "1" are language neutral. Methinks you are getting desperate for arguments here. :-) Or should we also remove "if" from the language? --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