Ethan Furman added the comment:
Guido van Rossum opined:
------------------------
> I still think the problem is with your class design.
> You shouldn't want a hex representation for a value
> that's not an integer.
Well, in fairness I only supported it because bool does, and I was trying to
have Logical match bool as closely as possible. Which is also why, in Py2,
attempting such operations on an Unknown value raises exceptions.
As an example:
# bool
--> True + True
2
# Logical
--> Truth + Truth
2
--> Truth + Unknown
Logical('?')
I can do that because I was able to override __add__ and __raddd__; however, if
I _do not_ overide index:
# bool
--> ['no', 'yes'][True]
'yes'
# Logical
--> ['no', 'yes', 'maybe'][Truth]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: list indices must be integers, not Logical
So either I break compatibility with bools in a rather fundamental way, or I
live with the eyesore of being able to use %x and %o on Unknown values.
Incidentally, bool is still not subclassable, and using int as a base class for
Logical blew up over half my tests.
Perhaps not quite so incidentally, if __index__ is added to an Enum (not
IntEnum) subclass, it will have the same wierdness.
Guido van Rossum stated:
------------------------
> For the difference between %x and hex() please open another
> issue (you might want to track down the cause in the source
> first so you can add a patch or at least a suggested fix to
> the issue).
Issue19995 is created, current participants nosied. I'll track it down as soon
as I can (may be a few days).
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue19988>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
