Comparisons and sorting of a numeric class....

Andrew Robinson andrew3 at
Tue Jan 6 14:30:43 CET 2015

>> So, I'm not sure I can subclass boolean either because that too is a
>> built in class ...  but I'm not sure how else to make an object that
>> acts as boolean False, but can be differentiated from false by the 'is'
>> operator.  It's frustrating -- what good is subclassing, if one cant
>> subclass all the base classes the language has?
> As I said above, make sure you have a constructor.  If you still get 
> an error, post a message that shows exactly what you did, and what 
> exception you saw.

I tried to subclass bool, using __new__ just to see if it would even 
accept the definition... eg: python 2.7.5

 >>> class UBool( bool ):
...     def __new__( self, default ): return bool.__new__( self, default )
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: Error when calling the metaclass bases
     type 'bool' is not an acceptable base type

I also tried using return int.__new__( self, bool(default) ) but that 
too failed the exact same way.

I came across this in my searches, perhaps it has something to do with 
why I can't do this?

I thought about this last night, and realized that you shouldn't be
allowed to subclass bool at all!  A subclass would only be useful when
it has instances, but 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.)  I think it's important not to provide a backdoor to
create additional bool instances, so I think bool should not be


--Guido van Rossum

So, I think Guido may have done something so that there are only two 
instances of bool, ever.
eg: False and True, which aren't truly singletons -- but follow the 
singleton restrictive idea of making a single instance of an object do 
the work for everyone; eg: of False being the only instance of bool 
returning False, and True being the only instance of bool returning True.

Why this is so important to Guido, I don't know ... but it's making it 
VERY difficult to add named aliases of False which will still be 
detected as False and type-checkable as a bool.  If my objects don't 
type check right -- they will likely break some people's legacy code...  
and I really don't even care to create a new instance of the bool object 
in memory which is what Guido seems worried about, rather I'm really 
only after the ability to detect the subclass wrapper name as distinct 
from bool False or bool True with the 'is' operator.  If there were a 
way to get the typecheck to match, I wouldn't mind making a totally 
separate class which returned the False instance; eg: something like an 
example I modified from searching on the web:

class UBool():
     def __nonzero__(self): return self.default
     def __init__( self, default=False ): self.default = bool(default)
     def default( self, default=False ): self.defualt = bool(default)

but, saying:
 >>> error=UBool(False)
 >>> if error is False: print "type and value match"

Failed to have type and value match, and suggests that 'is' tests the 
type before expanding the value.
It's rather non intuitive, and will break code -- for clearly error 
expands to 'False' when evaluated without comparison functions like ==.

 >>> if not error: print "yes it is false"
yes it is false
 >>> print error.__nonzero__()
 >>> if error==False: print "It compares to False properly"

So, both 'is' and == seems to compare the type before attempting to 
expand the value.
As a simple cross check, I tried to make a one valued tuple.

 >>> a=(False,None)
 >>> print a
(False, None)
 >>> a=(False,)
 >>> if a is False: print "yes!!!"
 >>> if not a: print "a is False"
 >>> if a == False: print "a is False"

but that obviously failed, too; and if == fails to say False==False ... 
well, it's just to sensitive for wrapper classes to be involved unless 
they are a subclass of bool...

Any ideas ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list