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).