Comparisons and sorting of a numeric class....
Andrew Robinson
andrew3 at r3dsolutions.com
Tue Jan 6 08:30:43 EST 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.
>
OK.
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?
https://mail.python.org/pipermail/python-dev/2002-March/020822.html
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
subclassable.
...
--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__()
False
>>> 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: <http://mail.python.org/pipermail/python-list/attachments/20150106/bcdd550b/attachment.html>
More information about the Python-list
mailing list