[Zope3-dev] Re: Riddle: zope.interface versus zope.formlib
Philipp von Weitershausen
philipp at weitershausen.de
Thu Aug 24 02:29:14 EDT 2006
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']
True
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
True
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.
Philipp
More information about the Zope3-dev
mailing list