[Zope-dev] Stripping down zope.component

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:

<snip>

>> 4. Rework zope.hookable to use a pure-Python implementation via
>>    descriptors, instead of the C extension.  Make it a non-optional
>>    dependency (but small and lightweight) of zope.component.  If
>>    *current* profiling shows that the hooked things are bottlenecks,
>>    make the C version and optional replacement for the Python version.
> 
> How do we do "current profiling"?

The existing implementation is the result of Jim's work profiling
component lookups back in 2002, using (I think) Python 2.2.  I'm
suggesting that we think about redoing the profiling against the
versions we care about (2.5, 2.6), and reconsider whether pure-Python
alternatives, using newer language features, might be sufficient.

For another example of this idea, see my proposal last fall to
reimplement the pickle cache inside persistent using pure Python:

 http://mail.zope.org/pipermail/zodb-dev/2008-September/012112.html

> Anyway, I'm +1 a pure-python implementation for zope.hookable, but we 
> need to get some grasp of the performance implications nonetheless. Does 
> anyone have any ideas on how determine the impact?

At the moment, the trunk of zope.component will use zope.hookable if it
is present, but fall back to a pure Python version if not.  If any of
the bench code Jim and others used back in the original optimization
pass is still around, the comparing / profiling the two implementations
is where I would start.

<snip>

> To get back to repoze.zcml: it is my understanding that repoze.zcml 
> contains some fixes to the way component registration is done in the 
> context of multiple WSGI applications. I'm no expert on this myself, so 
> I may understand this wrong, but that is my understanding.
> 
> If that is correct, we could look at applying these lessons to 
> zope.componentzcml.

That isn't correct.  repoze.zcml provides only alternative security-free
directive handlers, registered in a separate XML namespace.  If other
folks want those handlers, they can use the package directly, or
somebody could migrate them into another zope.* package.


> The trouble starts because we'd also need to apply those lessons to 
> grokcore.component as well, which doesn't need to depend on 
> zope.componentzcml at all.

ZCML isn't really relevant:  the problem I think you are worrying about
is actually in zope.component ("one global registry to rule them all").
The bits I think you are talking about are inside repoze.bfg's component
registry setup code:

 http://svn.repoze.org/repoze.bfg/trunk/repoze/bfg/registry.py

which makes the "global" registry actually bound to a specific
"application".  I don't know how reusable the code for that is, but the
idea should be liftable.

> So it would seem applying this knowledge would touch quite a few places, 
> and my instinct is to look for a way to share the implementation and 
> knowledge in a single place. We might be able do this by placing some 
> basic action implementations (or at least code that helps implementing 
> such actions) in zope.component itself. This would NOT implement any 
> ZCML directives nor introduce any dependencies (not even 
> zope.configuration), but would be an API implementers of configuration 
> mechanisms could then use.
> 
> Perhaps this is overkill or not possible; I don't quite understand the 
> issues involved, but I hope someone who does chips in.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJryLa+gerLs4ltQ4RAmGBAKDTJQUUxcisSbUoogkmhEdXxQkBHQCgr/9i
o+4meVIViWXh7E/I6SwNies=
=ptBg
-----END PGP SIGNATURE-----