I wondered to myself today while reading through the Python tutorial whether it would be a good idea to have a separate boolean type in Py3K. Would this help catch common mistakes? I won't presume to truly understand the new-to-Python experience, but one might *guess* that >>> 5 > 3 true would make a little more sense to a beginner than >>> 5 > 3 1 Of course this means introducing "true" and "false" as keywords (or built-in values like None -- perhaps they should be spelled True and False?) and completely changing the way a lot of code runs by introducing a bunch of type checking, so it may be too radical a change, but -- And i don't know if it's already been discussed a lot, but -- I thought it wouldn't hurt just to raise the question. -- ?!ng
"KY" == Ka-Ping Yee <ping@lfw.org> writes:
KY> I wondered to myself today while reading through the Python KY> tutorial whether it would be a good idea to have a separate KY> boolean type in Py3K. Would this help catch common mistakes? Almost a year ago, I mused about a boolean type in c.l.py, and came up with this prototype in Python. -------------------- snip snip -------------------- class Boolean: def __init__(self, flag=0): self.__flag = not not flag def __str__(self): return self.__flag and 'true' or 'false' def __repr__(self): return self.__str__() def __nonzero__(self): return self.__flag == 1 def __cmp__(self, other): if (self.__flag and other) or (not self.__flag and not other): return 0 else: return 1 def __rcmp__(self, other): return -self.__cmp__(other) true = Boolean(1) false = Boolean() -------------------- snip snip -------------------- I think it makes sense to augment Python's current truth rules with a built-in boolean type and True and False values. But unless it's tied in more deeply (e.g. comparisons return one of these instead of integers -- and what are the implications of that?) then it's pretty much just syntactic sugar <0.75 lick>. -Barry
On Fri, 17 Mar 2000, Barry A. Warsaw wrote:
Almost a year ago, I mused about a boolean type in c.l.py, and came up with this prototype in Python.
-------------------- snip snip -------------------- class Boolean: [...]
I think it makes sense to augment Python's current truth rules with a built-in boolean type and True and False values. But unless it's tied in more deeply (e.g. comparisons return one of these instead of integers -- and what are the implications of that?) then it's pretty much just syntactic sugar <0.75 lick>.
Yeah, and the whole point *is* the change in semantics, not the syntactic sugar. I'm hoping we can gain some safety from the type checking... though i can't seem to think of a good example off the top of my head. It's easier to think of examples if things like 'if', 'and', 'or', etc. only accept booleans as conditional arguments -- but i can't imagine going that far, as that would just be really annoying. Let's see. Specifically, the following would probably return booleans: magnitude comparisons: <, >, <=, >= (and __cmp__) value equality comparisons: ==, != identity comparisons: is, is not containment tests: in, not in (and __contains__) ... and booleans would be different from integers in that arithmetic would be illegal... but that's about it. (?) Booleans are still storable immutable values; they could be keys to dicts but not lists; i don't know what else. Maybe this wouldn't actually buy us anything except for the nicer spelling of "True" and "False", which might not be worth it. ... Hmm. Can anyone think of common cases where this could help? -- n!?g
On Fri, 17 Mar 2000, Barry A. Warsaw wrote:
Almost a year ago, I mused about a boolean type in c.l.py, and came up with this prototype in Python.
Cool prototype! However, I think I have a problem with the proposed semantics:
def __cmp__(self, other): if (self.__flag and other) or (not self.__flag and not other): return 0 else: return 1
This means: true == 1 true == 2 But 1 != 2 I have some difficulty with == not being an equivalence relation...
I think it makes sense to augment Python's current truth rules with a built-in boolean type and True and False values.
Right on! Except for the built-in...why not have it like exceptions.py, Python code necessary for the interpreter? Languages which compile themselves are not unheard of <wink>
But unless it's tied in more deeply (e.g. comparisons return one of these instead of integers -- and what are the implications of that?)
Breaking loads of horrible code. Unacceptable for the 1.x series, but perfectly fine in Py3K -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com
Yes. True and False make sense. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido: (re None being a keyword)
Yes.
Guido: (re booleans)
Yes. True and False make sense.
Ka-Ping: Astounding. I don't think i've ever seen such quick agreement on anything! And twice in one day! I'm think i'm going to go lie down.
No, no, keep going --- you're on a roll. Greg
Guido van Rossum wrote:
Yes. True and False make sense.
mx.Tools defines these as new builtins... and they correspond to the C level singletons Py_True and Py_False. # Truth constants True = (1==1) False = (1==0) I'm not sure whether breaking the idiom of True == 1 and False == 0 (or in other words: truth values are integers) would be such a good idea. Nothing against adding name bindings in __builtins__ though... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (6)
-
Barry A. Warsaw -
Guido van Rossum -
gvwilson＠nevex.com -
Ka-Ping Yee -
M.-A. Lemburg -
Moshe Zadka