[Python-Dev] Comparison inconsistency with ExtensionClass

[Jim Fulton]

Greg Ward wrote:
> 
> Hi all --
> 
> I seem to have discovered an inconsistency in the semantics of object
> comparison between plain old Python instances and ExtensionClass
> instances.  (I've cc'd python-dev because it looks as though one *could*
> blame Python for the inconsistency, but I don't really understand the
> guts of either Python or ExtensionClass enough to know.)

(demonstration snipped)

> The first one and the last two are obvious, but the second one only
> works thanks to a trick in PyObject_Compare():
> 
>     if (PyInstance_Check(v) || PyInstance_Check(w)) {
>         ...
>         if (!PyInstance_Check(v))
>             return -PyObject_Compare(w, v);
>         ...
>     }
> 
> However, if I make Simple an ExtensionClass:
> 
>     from ExtensionClass import Base
> 
>     class Simple (Base):
> 
> Then the "swap v and w and use w's comparison method" no longer works.
> Here's the output of the script with Simple as an ExtensionClass:
> 
>     v1 == v2? no
>     v2 == v1? Simple.__cmp__: self=<Simple at 1b51c0: 36>, other=36
>     yes
>     v1 == v2.data? yes
>     v2.data == v1? yes
> 
> It looks as though ExtensionClass would have to duplicate the trick in
> PyObject_Compare() that I quoted, since Python has no idea that
> ExtensionClass instances really should act like instances.  This smells
> to me like a bug in ExtensionClass.  Comments?

Technically, this *is* a bug in ExtensionClass, however, Python
*does* deserve some of the blame. The intepreter actually uses the
following rule:

  Instances of two different "python types" are not compared
  using type-supplied comparison methods unless:

  - At least one of the types is InstanceType or

  - Both of the types are numeric.

This rule is rather inconvenient for ExtensionClass.
It's also pretty inconvenient for non-ExtensionClass
non-numeric extension types that want to be comparable with 
other things.

You can work around this by making your ExtensionClass a numeric
type. This should be possible by providing a numeric method.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.