directlyProvidedBy and friends don't work on ContainedProxy

[Jacob Holm]

Calling zope.interface.directlyProvidedBy on a zope.app.container.contained.ContainedProxy always returns an empty Declaration.
This causes zope.interface.alsoProvides and zope.interface.noLongerProvides to fail as well.
(alsoProvides becomes identical to directlyProvides and noLongerProvides clears all directly provided interfaces).

I have found the problem (the __get__ method of ContainedProxyClassProvides inherited from zope.interface.ClassProvides) and will post a patch in a few minutes.

(This bug is completely unrelated to https://bugs.launchpad.net/bugs/185054 except for the fact that they both concern ContainedProxy)

[Jacob Holm (jacobholm)]

I have changed ContainedProxyClassProvides to inherit directly from Declaration instead of from ClassProvides.
This way we avoid creating the _implements attribute which is not useful in the context of ContainedProxies, because we must delegate to the proxied object.

Note that I *do* have commit privileges, so I can apply the patch myself if need be. However, I don't know the current procedure for making a release. Pointers are welcome.

[Philipp von Weitershausen (philikon)]

On 24 Jan 2008, at 00:02 , Jacob Holm wrote:
> I have changed ContainedProxyClassProvides to inherit directly from
> Declaration instead of from ClassProvides.
> This way we avoid creating the _implements attribute which is not
> useful in the context of ContainedProxies, because we must delegate
> to the proxied object.

Cool. But, afaik ContainedProxies are persistent. Will this change
break old databases (pickles)?

> Note that I *do* have commit privileges, so I can apply the patch
> myself
> if need be. However, I don't know the current procedure for making a
> release. Pointers are welcome.

Some guidelines about maintaining and releasing software that's in
svn.zope.org are here: http://svn.zope.org/Sandbox/philikon/foundation/

[Jacob Holm (jacobholm)]

The pickle format for the new version of ContainedProxyClassProvides is identical to the old one, so that change won't break anything. Also, no ContainedProxyClassProvides instances are pickled under normal circumstances, because the class is a descriptor whose purpose is to combine the interfaces implemented by the proxy class with the directly provided interfaces of the proxied object.

The problem was that the inherited __get__ method looked at the proxy instead of the proxied object, while the __set__ and __delete__ did the right thing.

[Jacob Holm (jacobholm)]

Hi Philipp. I just finished reading the very nice guidelines you linked to, and I have a few questions:

1) Is the recommended practice to work in the trunk or in the release branch? Does it matter?

2) The current version number in zope.app.container/trunk/setup.py is 3.6.0 without a "dev" suffix. Should it have one? And would it cause problems for someone if I changed that?

3) Who can upload new releases? What responsibilities are associated with that privilege? Who grants it?

4) I have access to a windows machine and can build binary eggs using MinGW. Would these be acceptable or do I need to find someone with the right Visual C toolchain? (The MinGW eggs have always worked flawlessly for me. YMMV)

[Tres Seaver (tseaver)]

This patch looks good to me, but needs to be targeted to zope.container, not zope.interface:. E.g.:

  $ cd /path/to/zope.container/trunk/src/zope/container
  $ patch -p4 < /tmp/185487.patch

[Colin Watson (cjwatson)]

The zope.container project on Launchpad has been archived at the request of the Zope developers (see https://answers.launchpad.net/launchpad/+question/683589 and https://answers.launchpad.net/launchpad/+question/685285). If this bug is still relevant, please refile it at https://github.com/zopefoundation/zope.container.