Stephan Richter wrote:
>  >>> from zope.interface import Interface
>  >>> from zope.schema import TextLine
>  >>> class IFoo(Interface):
>  ...     title = TextLine()
>  ...
>  >>> class IBar(IFoo):
>  ...     pass
>  ...
>  >>> IBar['title']
>  <zope.schema._bootstrapfields.TextLine object at 0xb7bc17ac>
>  >>> IBar['title'].interface

It's obviously IFoo, because:

  >>> IBar['title'] is IFoo['title']

I sort of expect this. Why? Because it also happens with classes:

  >>> class Foo(object):
  ...   x = object()
  >>> class Bar(Foo):
  ...   pass
  >>> Bar.x is Foo.x

Now, you could say that interfaces don't necessarily have follow class
semantics just because they're defined via the class statement....

> Either way you look at it, one package is wrong and thus broken.
> But which is it? It turns out that zope.interface wins and IFoo is returned. 
> This really hurts zope.formlib. After an initial discussion on IRC, more 
> people expected IBar, since it is more in line with im_class, but there were 
> also people expecting IFoo.

Yeah, I don't see how the parallel has to draw to im_class. im_class is
about instance methods. Instance methods are functions bound to
instances. That doesn't happen with interface specification objects like
Attributes, Fields, etc. Perhaps it should?

I don't see anything wrong with the current semantics.


Zope3-dev mailing list

Reply via email to