RE: [Python-Dev] bool does not want to be subclassed?
[Guido] the mere existance of an instance of a subclass of bool would break the invariant that True and False are the only instances of bool! (An instance of a subclass of C is also an instance of C.)
[François] This is a convincing argument, and enough a reason. Thanks! Now, I know why Python refuses! :-)
I don't think I'm convinced; the same argument could be used for integers (if it doesn't make sense to create a sort of boolean which isn't in the set { true, false }, then it doesn't make sense to create a sort of integer which isn't in the set { ..., -2, -1, 0, 1, 2, ... }). And maybe it doesn't, but this isn't the only reason for subclassing. Another reason for subclassing is to create items which can act like existing objects, but which have some additional behavior.
Joshua Marshall wrote:
I don't think I'm convinced; the same argument could be used for integers (if it doesn't make sense to create a sort of boolean which isn't in the set { true, false }, then it doesn't make sense to create a sort of integer which isn't in the set { ..., -2, -1, 0, 1, 2, ... }). And maybe it doesn't, but this isn't the only reason for subclassing. Another reason for subclassing is to create items which can act like existing objects, but which have some additional behavior.
And indeed, for int, it is possible to have subclasses which have new instances whose values are in the set {..., -2, -1, 0, 1, 2, ...}. Indeed, it is possible to have multiple instances of int *itself* whose value is, say, 1000:
500+500 is 500+500 False
The same is not true for bool: There are only two *instances* of the type, not just two equivalence classes of equal values:
(4>5) is (3>9) True
So bool guarantees: a) there are only two distinct values, and b) there are only two different objects representing these values. It is property b) which prohibits subclassing. Regards, Martin
Martin:
So bool guarantees: ... b) there are only two different objects representing these values.
Why is this property so important? I can understand why it's useful for there to be only one None, since programs do 'x is None' a lot. But it's not as if you can get away with saying 'x is True' or 'x is False' all over the place. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Greg Ewing]
Martin:
So bool guarantees: ... b) there are only two different objects representing these values.
Why is this property so important?
When I read the quote from Guido speaking about code invariants, I presumed that the internal code for `bool' uses things like: if SUCH is True: ... else: ... relying on the facts that 1) if SUCH is true, than SUCH _is_ True, and also, 2) that SUCH not being True means that it is necessarily False. These surely allow for a simple and efficient `bool'. -- François Pinard http://www.iro.umontreal.ca/~pinard
there are only two different objects representing these values.
Why is this property so important?
I can understand why it's useful for there to be only one None, since programs do 'x is None' a lot. But it's not as if you can get away with saying 'x is True' or 'x is False' all over the place.
Why is it important *not* to have this property? Maintaining it is trivial, and it helps the implementation a bit (it's actually *natural* to have only the two instances). --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido van Rossum]
there are only two different objects representing these values.
Why is this property so important?
I can understand why it's useful for there to be only one None, since programs do 'x is None' a lot. But it's not as if you can get away with saying 'x is True' or 'x is False' all over the place.
Why is it important *not* to have this property? Maintaining it is trivial, and it helps the implementation a bit (it's actually *natural* to have only the two instances).
It is not so _important_ *not* to have this property. However, if it did not have this property, this would allow for sub-classing `bool', something useful at times, as I tried to explain in previous messages. The usefulness of sub-classing `bool' would likely not be worth any significant slow-down of the implementation. Yet, if the slowdown was not to be significant, than it might be worth removing the restriction about `bool' not allowing sub-classing, so making it more like `int', and most other types. I was surprised at first to see that `bool' could not be subclassed, and so, I asked why; the explanations given on this list have been helpful. On the other hand, Python should _ideally_ try to limit the number of limitations which surprise users. That ideal is difficult, as Python has many complex corners when you dive a bit under the surface, and some of these complexities just peek through the surface, once in a while. -- François Pinard http://www.iro.umontreal.ca/~pinard
Guido:
Why is it important *not* to have this property?
Probably not greatly important, it just seems to me that there ought to be a fairly strong reason for taking the somewhat drastic step of making something non-subclassable.
it helps the implementation a bit
Only a tiny bit, surely? Anything which accepts a boolean has to be prepared to deal with any type of object anyway. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
[Joshua Marshall]
[...] if it doesn't make sense to create a sort of boolean which isn't in the set { true, false }, then it doesn't make sense to create a sort of integer which isn't in the set { ..., -2, -1, 0, 1, 2, ... }.
Merely chatting, here. In that same big application for which I considered (for a short moment) sub-classing `bool' to "mark" booleans with their computation origin, we have a particular other kind-of-boolean type, heavily used in the application, which runs six values from full falsity to full truth. Python surely made it very elegant. This one, I would have never ever considered sub-typing from `bool' :-). For fun, we named the constructor `poul' and we speak of pouleans, as a friendly tease to the mathematician in the team who decided the details of this particular logic (Jacques Poulin). About interesting extensions to integers, and to all kind of numbers in fact, including wet ones :-), a good read is the John Conway book: "On games and numbers". However, it is not worth a Python module yet! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard
"François Pinard" <pinard@iro.umontreal.ca> wrote in message news:20040213170139.GA14216@alcyon.progiciels-bpi.ca... About interesting extensions to integers, and to all kind of numbers in fact, including wet ones :-), a good read is the John Conway book: "On games and numbers". However, it is not worth a Python module yet! :-) rather, On Numbers and Games (ONAG. 1976) Berlekamp, Conway, & Guy; Winning Ways...(1982) has some similar material Terry J. Reedy
participants (6)
-
"Martin v. Löwis" -
François Pinard -
Greg Ewing -
Guido van Rossum -
Joshua Marshall -
Terry Reedy