Unstated assumptions about the IAnnotations interface

Bug #98462 reported by Jacob Holm
2
Affects Status Importance Assigned to Milestone
Zope 3
Won't Fix
Medium
Unassigned
zope.annotation
Fix Released
Medium
Tres Seaver

Bug Description

Parts of zope 3 assume that the result of adapting an object to IAnnotations support "__contains__", "__iter__" and "items". This is true for the standard adapter(s) but is not part of the documented interface.

__contains__ is easy to implement in terms of the existing interface, so adding this to the interface is only a small burden on implementers.

__iter__ and items may be more difficult to support in some cases.

Tags: bug core
Revision history for this message
Jacob Holm (jacobholm) wrote :

For example, grepping for "in annotations" finds examples of all three (one false positive filtered out):

/zope3/src/optionstorage/__init__.py:
        if OptionStorageKey in annotations:
/zope3/src/optionstorage/__init__.py:
            if OptionStorageKey in annotations:
/zope3/src/zope/app/apidoc/codemodule/browser/introspector.py:
        for key, value in annotations.items():
/zope3/src/zope/app/zopeappgenerations/evolve5.py:
            if DCkey in annotations:
/zope3/src/zope/fssync/server/syncer.py:
            for key in annotations:

Revision history for this message
Christian Theune (ctheune) wrote :

You're right.

This appears to be a problem that people are mostly using
attribute annotations which inherit from UserDict.DictMixin.

I agree that the current situation should be changed.

I can see two ways:

1. Extend the IAnnotations interface to grow the necessary
  methods and support the existing use cases

2. Remove the ability from the existing attribute annotation
  and re-write the code that uses it to avoid using __iter__
  __contains__ and items.

Im personally in favor of option 1 because the code that uses it
IMHO proves that those methods would be useful in the interface.

Backwards-compatibility is at risk because existing IAnnotations
implementations need to supply the new methods. However, doing
so should not be too much of a burden for any IAnnotations implementation, but I might be wrong there.

I'll move the discussion to the mailinglist to find consensus for this issue.

Revision history for this message
Christian Theune (ctheune) wrote :

Changes: submitter email, edited transcript, topic (community => core), revised version_info, new comment

Updated version and topic.

Revision history for this message
Christian Theune (ctheune) wrote :

Changes: importance (medium => 3.3 Release), new comment

At least something is broken and considerably a bug. We should have *some* change in the next 3.3 release.

Changed in zope3:
status: New → Confirmed
Tres Seaver (tseaver)
Changed in zope.annotation:
importance: Undecided → Medium
status: New → Confirmed
Changed in zope3:
status: Confirmed → Won't Fix
Revision history for this message
Tres Seaver (tseaver) wrote :
Changed in zope.annotation:
assignee: nobody → Tres Seaver (tseaver)
status: Confirmed → Fix Committed
Revision history for this message
Tres Seaver (tseaver) wrote :
Changed in zope.annotation:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.