On Mon, Oct 25, 2010 at 11:14:21PM +0100, David Glick wrote:
> 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?

I like this.

> >> 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?

Or perhaps make it emit DeprecationWarnings, but continue working.  Then
make it a fatal error in the next minor/major release.

Marius Gedminas
Include me out.

Attachment: signature.asc
Description: Digital signature

For more information about ZODB, see the ZODB Wiki:

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

Reply via email to