[Zope3-dev] possible bug in catalog code

[Jim Fulton]

Martijn Faassen wrote:
> Hi there,
> 
> in zope.app.catalog.attribute, there's the following functionality:
> 
>     def index_doc(self, docid, object):
>         if self.interface is not None:
>             object = self.interface(object, None)
>             if object is None:
>                 return None
> 
>         value = getattr(object, self.field_name, None)
>         if value is None:
>             return None
> 
>         if self.field_callable:
>             try:
>                 value = value()
>             except:
>                 return None
> 
>         return super(AttributeIndex, self).index_doc(docid, value)
> 
> The following sequence I think leads to trouble:
> 
> 
>         value = getattr(object, self.field_name, None)
>         if value is None:
>             return None
> 
> as this means attributes that do exist and have the value None would 
> never be indexed (as index_doc() is never reached).
> 
> Instead, I'd suggest the following code:
> 
>         try:
>             value = getattr(object, self.field_name)
>         except AttributeError:
>             return None
> 
> or alternatively if for some reason getattr() with a default is 
> preferred (though I suspect the exception approach is slightly faster):
> 
> # module level
> NotFound = object()
> 
>         value = getattr(object, self.field_name, NotFound)
>         if value is NotFound:
>              return None
> 
> If this is indeed decided to be a bug, is it okay if I check in a fix 
> for this? I'll try to devise a test of course.

I'm not sure if this is a bug.  If it is, the fix might be worse.
It makes no sense and could cause problems to use None as a BTree-bases
index key. AFAICT, Python still makes no guarantee wrt comparison of
of objects of different types over time:

   http://docs.python.org/ref/comparisons.html

   "The operators <, >, ==, >=, <=, and != compare the values of two objects.
    The objects need not have the same type. If both are numbers, they are
    converted to a common type. Otherwise, objects of different types always
    compare unequal, and are ordered consistently but arbitrarily.

    (This unusual definition of comparison was used to simplify the definition of
    operations like sorting and the in and not in operators. In the future, the
    comparison rules for objects of different types are likely to change.)"

It would only be safe to use None as a BTree key if all of the keys used
were None, which wouldn't be very interesting. :)

There are various ways that one could design an index that would
handle objects of different types, if necessary or handle None as
a special case.  Thar would require a fairly different design.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org