Grégoire Weber wrote:
> while modeling the external API of an application I'd like to use the
> tagged value feature of the interface implementation.
> It seems to me that handling tagged values is implemented inconsequently.
> It would be nice if tagging attributes and interfaces would look the
> same as tagging methods:
> in the interface definition:
>     meth.tag = 'tagged' # interrestingly ``meth.setTaggedValue`` doesn't work

This is, for example, useful for setting the precondition on __setitem__
method defintions for containers::

  class IRecipeContainer(IContainer):
      def __setitem__(name, object):
          """Add a recipe"""
      __setitem__.precondition = ItemTypePrecondition(IRecipe)

Having to use setTaggedValue would be a lot less syntactic sugar for

>     attr.tag = 'tagged' # have to use ``attr.setTaggedValue('tag',
> 'tagged')`` currently
> on module level:
>     IGaga.tag = 'tagged' # have to use ``IGaga.setTaggedValue('tag',
> 'tagged')`` currently
> See code below with traces.
> I didn't dig deep enough into the interface implementation to find out
> why. I may try. Any hints?

API inconsistencies usually have no specific reasons other than
bitrotting, I guess.

I would say that a 'setTaggedValue' method is a bit unpythonic (it
actually feels quite Javaish). I realize that the concept of tagged
values is well known from UML, that doesn't mean we can use pythonic
idioms for it though. I personally would prefer using the
__getitem__/__setitem__ protocol for this, but interfaces unfortunately
already use this for accessing interface members (e.g. IRecipe['name']).
I wish they would use the __getattr__ protocol (e.g.
Maybe it's not too late to change this, though it would be hard. It
would also make IInterface really tricky (what would
IInterface.implementedBy be?).

Zope3-dev mailing list

Reply via email to