[Zope3-dev] Interface.Implements module still broken for 2.2 metaclasses

[Phillip J. Eby]

At 12:01 PM 7/8/02 -0400, Jim Fulton wrote:
>
>We need some unit tests that demonstrate both kinds of breakage.

Both?  I provided an example for getImplementsOfInstances(); it can also be
used as an example for getImplements().


>A work-around for now is to implement an isinstance in Python for use here.

Why?  It's not needed, as far as I can see.


>This would penalize all objects though, which wouldn't ne nice. :(

The difference between calling:

type(x) in sometuple

and:

isinstance(x,sometuple)

should be negligible in performance.  The current Python isinstance() does
the right thing now.  The future 2.3 isinstance() will do a "more right"
thing later.

I think y'all are making this much more complicated than it actually is.
If you need it to support 2.1, it isn't that hard to have two versions of
getImplements()/getImplementsOfInstances(), with the right one defined
based on the version.


>Phillip, what about making your meta-classes have their own __implements__
>attribute. That would be much cleaner, IMO.

I did that.  It still breaks getImplementsOfInstances()!
getImplementsOfInstances() assumes that if something isn't TypeType or
ClassType, it can't have instances, and therefore doesn't even bother
checking for __implements__!

My metaclass works around the getImplements() problem by providing
__class_implements__ when the class is asked for __implements__.  This
workaround works just fine, though I'd prefer to be rid of it.

The problem is that my previous workaround for the
getImplementsOfInstances() problem was to provide an .instancesImplement()
method on my metaclass instances, which is no longer being called by the
Interface package.  (I even had to provide it under two names previously:
instancesImplement and instancesImplements, because Zope 2 and 3 looked for
it under different names for a while!)

>From my POV, the Zope 3->2.6 backport of the Interface package broke
existing functionality of previous versions of the Interface package.  The
old Interface package, you could get 2.2 metaclasses to work with, if you
jumped through enough metaclass and descriptor hoops.  The new one, you
can't.  There is no workaround that doesn't involve monkeypatching or an
actual fix.

What this means is, I can't tell somebody to download the Zope 2.6
Interface package to use with PEAK.  I have to refer them to an out-of-date
version in order to have something whose limitations I can at least hack
around.

My proposed change should have negligible performance impact (possibly
positive!), and no functional impact for anything in Zope 3 or 2 that
doesn't rely on the broken behavior.  (And I can't fathom what could
possibly want to depend on said broken behavior.)  What's more, it'll make
it possible for 2.2 metaclass users to leverage the Interface package,
without jumping through any hoops.  Assuming Steve's test run verifies that
it doesn't affect anything in Zope 3, what's not to like?