[ZODB-Dev] 0 is not really equal to my object

[Derrick Hudson]

On Tue, Feb 08, 2005 at 04:45:17PM -0500, Tim Peters wrote:
| [Derrick Hudson]
| > The attached script shows the problem I discovered.  Adjust the path
| > at the beginning to refer to your zope installation.  The problem only
| > exhibits itself when the class inherits from Persistent.
| 
| Or derives in any other way from ExtensionClass,

Ok, I wasn't sure how far up or down the inheritance hierarchy this
would appear.

[...]

| Under ZODB 3.2.5, that produced this output (and it would have helped had
| you been this specific about the output you got):

Sorry, I thought it was clear enough that 0 was not supposed to equal
Infinite :-).

| In ZODB 3.3, Persistent no longer derives from ExtensionClass, and is a
| vanilla "new-style" Python class (albeit coded in C) instead.  The import
| has to change then, to:

Right, but that doesn't help me unless I could totally rewrite the app
for ZopeX3 :-).

| > To summarize, if an (in)equality comparison is performed and the int 0
| > is on the left-hand side of the comparison, the result is inverted.
| >
| > I am using zope 2.7.1 with python 2.3.4 on debian linux.  (this is
| > part of a Z4I-based project)
| >
| > Will someone confirm this as a bug or point out something I am doing
| > wrong?
| 
| Well, *I'd* call it a bug, but at the same time I don't think there's a real
| chance it will be fixed before ZODB 3.3 (where it's already fixed).  Mucking
| with the ExtensionClass implementation before then is as likely to introduce
| as many new bugs as got fixed (it's complicated, deep black-magic C code).

Ok.  Maybe a collector issue should be opened to help people find this
existing knowledge about it?  I did search the collector before
posting.

| Googling on
| 
|      ExtensionClass comparison
| 
| turns up a suggested workaround from 2000, but I'm afraid I don't understand
| it:
| 
|     http://mail.python.org/pipermail/python-dev/2000-October/010117.html
| 
| (Best guess is that "make your ExtensionClass a numeric type" is something
| that can only be done at the C level; adding methods like __nonzero__() to
| your class doesn't make any difference to the results printed by your
| program on my box under ZODB 3.2.5)
| 
| I think the last time this was discussed on zodb-dev starts here:
| 
|     http://mail.zope.org/pipermail/zodb-dev/2003-June/005430.html

These threads nail the problem on the head.  Thanks for that!  I
suppose I would have found them if I searched for ExtensionClass
instead of Persistent.

I see now why the __cmp__ isn't called in the specific problem
scenario:  ECType->ob_type is not PyInstance_Type.  I don't see
why/how the object is coerced to 0, but that isn't so important.


| I stand by my claim there that nobody can predict when an ExtensionClass's
| __cmp__() will get invoked during mixed-type comparisons.

Long live python 3k ;-).

| So best advice I
| can give is to abandon this approach, and try something else.

I have a content type in my system where a certain field is an Int.
However, under some circumstances the user needs to input "unlimited"
instead of a finite integer.  So, I am creating a new Schema
field+widget to handle this scenario.  I am subclassing the existing
Int and IntWidget.  My Infinite class is supposed to be a
well-behaved sentinel value.  

Do you have any recommendations, off-hand, on how to achieve that?

New-style classes and EC don't mix:
    class Infinite(int, Persistent)

    TypeError: metaclass conflict

and not being persistent gives me other internal errors:
    class Infinite(int)

    PicklingError: Can't pickle <class
    'Products.ROSInfoSys.fields.infinite.Infinite'>: it's not the same
    object as Products.ROSInfoSys.fields.infinite.Infinite

Perhaps I just can't do this with ZODB < 3.3 (and therefore zope <= 2.7).

At least I can use "float('inf')" for my sentinel value to work around
this problem.

Thank you for your help on this!
-D

-- 
One OS to rule them all, one OS to find them,
One OS to bring them all and in the darkness bind them,
In the Land of Redmond, where the Shadows lie.
 
www: http://dman13.dyndns.org/~dman/            jabber: dman at dman13.dyndns.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zodb-dev/attachments/20050208/99146106/attachment.bin