zope.proxy is harder. :( What's especially sad is that the dependency
on it is rather unimportant. It is used by zope.deferredimport. I
was forced to use proxies because of annoying limitations in Python's
module implementation and the inspect module's assumption that a
module is not a module unless it subclasses the standard Python module
type. I expect though that a simpler proxy implementation could be
used by deferredimport. This would make zope.component depend on
zope.proxy only if the annoying zcml is used.
On Sun, 2008-04-20 at 01:16 +0200, Martijn Faassen wrote:
> Hi there,
> Another high-level response. I actually *hope* that the port Zope
> packages to Jython project will be accepted for the Google Summer of
> Code. If it does, the python versions of this code will be given a
> good workout by the student, which should benefit other porting
> projects as well. cc-ing the student. Georgy, if you aren't aware yet,
> please check out this thread on zope3-users; it may have some
> interesting information for your project.
A little investigation shows me that Jim is correct.
1. zope.interface 'just works' as pure-python
2. zope.component depends on zope.proxy:
a. in zcml.py. (I probably wouldn't be using zcml in my experiment)
b. by its dependency on zope.deferredimport
If I have understood the code correctly in zope.deferredimport the
problem which zope.proxy.ProxyBase answers is in the following snippet
from z.deferredimport.deferredmodule:initialize  where a type(module)
comparison is made.
Therefore, if I could understand fully Jim's statement:
"the inspect module's assumption that a module is not a module unless it
subclasses the standard Python module type"
Then I could attempt to substitute pure-python code for the type(module)
problem which appears in the `initialize` method.
__name__ = sys._getframe(level).f_globals['__name__']
module = sys.modules[__name__]
if not (type(module) is ModuleProxy):
module = ModuleProxy(module)
sys.modules[__name__] = module
if level == 1:
Zope3-users mailing list