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):
>>> 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