On Jan 7, 2008, at 3:54 PM, Dieter Maurer wrote:
Under some circumstances "zope.interface" adds a "__provides__"
to a class. The descriptor is implemented in
"zope/interface/_zope_interface_coptimizations.c" and called

While "__implements__" is inherited by derived classes,
the inherited "__provides__" refuses to work for a derived class
and raises "AttributeError: __provides__" instead,
the AttriuteError, I observe....

That is intentional.

If "__implements__" is inherited, why is "__provides__" not

__provides__ (in this context) is a class attribute. I don't support (and don't want to support) inheritance between class objects.

I will try to make my failure independent of "ManagableIndex"
and then file a bug report.

I'm unclear why this caused a problem for you. You never said, afaict,
what actually broke for you.  What expectation did you have that is

"inspect" does no longer work reliably.

I expected as much. inspect is broken.

  "inspect.getmembers" and "inspect.classify_class_attrs"
  require that for each "name" in "dir(cls)" "getattr(cls, name)"
  does not raise an exception.

This fails for classes magically stuffed with a "__provides__"

It also fails for any descriptor that sometimes raises attribute errors. Someone should report this as an inspect bug. This would be so easy to fix.

As a consequence, "pydoc" (which sits on top of inspect) fails --
and therefore "dm.zdoc".

That's what you get for building on a broken foundation.

I suggest monkey-fixing inspect.getmembers. This is a small function that should be easy to replace with a non-broken version.

My main gripe with the way this works is that classes get mutated. If
I ever redo this someday, I'd use a data structure external to the
classes.  Modifying the classes was a mistake.

Yes. That, too, would have avoided the bug.

Yes, it would have avoided the inspect bug. IMO, it would also have been cleaner. If someone wants to volunteer to change it, I'll try to provide some oversight. Unfortunately, it's not a small task, which is why I'm not volunteering to do it.


Jim Fulton
Zope Corporation

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to