On 10/25/10 11:07 PM, Jim Fulton wrote:
> On Mon, Oct 25, 2010 at 5:58 PM, David Glick <davidgl...@groundwire.org> 
> wrote:
>> On 10/25/10 10:51 PM, Jim Fulton wrote:
>>> I'm inclined to treat the use of the comparison operator inherited
>>> from object in BTrees to be a bug.  I plan to fix this on the
>>> trunk.
>>> I'm tempted to fix this in 10.1.  This change would make it impossible
>>> to add keys to BTrees or buckets or to add items to BTree-based
>>> sets if the key or items inherits it's comparison from object.  This
>>> would only apply to instances of new-style classes, including
>>> persistent objects. (It wouldn't affect old-style-class instances,
>>> which are too hard to introspect.)
>>> Thoughts?
>> The motivation here is that the comparison inherited from object
>> compares the objects' memory locations, which is not stable beyond
>> deactivation for persistent objects, and therefore not suitable for use
>> as a BTree key. Correct?
> Yup. Thanks for clarifying.
>> Preventing people from making that mistake
>> sounds like a good thing to me.
> It will likely reveal that current applications are broken.
> This will likely cause some pain.  Where previously,
> apps simply lost data, now they'll error.  I'm afraid that
> this might be too disruptive for a bug-fix release.
Maybe add it as an option defaulted to off? So that app developers who
want to check whether they have this problem can easily do so, and have
the extra protection once they've fixed any issues?
David Glick
 Web Developer

Groundwire: You Are Connected           

Online tools and stratgies for the environmental movement.  Sign up for 
Groundwire News!
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to