Re: [Zope-dev] Recursive search of dependencies in z3c.autoinclude
Hey, These sound good to me, as long as they're off by default, have tests, and don't break existing behavior. includeDependencies package=. recursive=True ignore=zope.app.zcmlfiles ice.control / This not include packages `zope.app.zcmlfiles` and `ice.control`, but include their dependencies. Does ignore= work on namespaces, or exact package names? What would happen if you did ignore=zope instead? Either way, could you add a test clarifying this behavior in dependency.txt? TODO: * Add ability for create autoconfigure.zcml file for decrease startup time. You mean, a static ZCML file that contains all the include directives that z3c.autoinclude auto-includes, in the right order? This is very cool -- I've always wanted to do this but never gotten around to it. The version number in CHANGES.txt and setup.py should be changed to 0.4.0, not 0.3.5 -- these are all new features. Do you have commit rights to merge these? -Ethan On Wed, Apr 6, 2011 at 3:28 PM, Cykooz cyk...@googlemail.com wrote: Hi, I release z3c.autoinclude with a lot of attributes for directives includeDependencies and includeDependenciesOverrides. Mercurial repository with my fork - https://bitbucket.org/cykooz/z3c.autoinclude. Recursive search of dependencies includeDependencies package=. recursive=True / This looks up and includes all respective ZCML files of packages you declared to depend on in setup.py. This works recursive so that if packages in your setup.py depend on others the latters are looked up too and so on (and everything in the right order). Disabling autoinclude some packages --- includeDependencies package=. recursive=True ignore=zope.app.zcmlfiles ice.control / This not include packages `zope.app.zcmlfiles` and `ice.control`, but include their dependencies. TODO: * Add ability for create autoconfigure.zcml file for decrease startup time. PS: I would be glad if my changes will merge with main branch. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New Zope 3 name: BlueBream
On Wed, Jan 6, 2010 at 10:44 AM, Hermann Himmelbauer du...@qwer.tk wrote: +1 on just bream from an interested bystander. Somehow the blue makes me think of microsoft. Microsoft, really? I guess it's some blurred combination of the blue color schemes I always associate with Windows, and the blue screen of death.. stuff like that.. Interesting, I personally think about IBM (Big Blue)... Whoa! I never knew that was a nickname for IBM! You've just explained the mystery of the Big Blue Disks I loved getting as a kid. I always wondered why they were called that. :) Well now suddenly I'm feeling very good vibes about the blue, thanks :) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New Zope 3 name: BlueBream
On Tue, Jan 5, 2010 at 9:29 AM, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: On Monday 04 January 2010, Baiju M wrote: I am proposing to call Zope 3 - the web frame work as BlueBream. The main use for name is documentation. But the package named bluebream will not provide any part of framework code by itself. All the framework code will be in zope and zope.app namespaces. I like the name too. As Simon suggested, a shorter Bream might be better. There is too much blue in technology already.. +1 on just bream from an interested bystander. Somehow the blue makes me think of microsoft. And bream is really easy to type on a qwerty keyboard but my fingers trip badly on bluebream. That l-u-e-b-r-e sequence is hard. -Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of Interfaces vs ZCA concepts
Hi, On Fri, Dec 18, 2009 at 9:47 AM, Lennart Regebro rege...@gmail.com wrote: On Fri, Dec 18, 2009 at 08:51, Brian Sutherland br...@vanguardistas.net wrote: I like things to fail noisily and loudly unconfigured and give good information about what's wrong. +1 [snip] we make zope.interface aware that such a thing as utility-registries exist, but say we don't implement it. I don't think that's a problem. The error message also gives an example of an implementation. That's probably not a problem either. I feel uncomfortable about that. I don't. :-) +1 from my perspective of I don't know or understand the core ZCA codebase very well (and don't understand all the implications in this discussion) but often read or trace through the code. A well-documented NotImplementedError seems much more human-useful than a default implementation that fulfills the contract, because it assertively announces the expectation for the most common case by far: you probably want to plug in a real implementation here. Then if there is a need for the proposed default implementation, it can be provided as a plugin by some other package, right? -Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of Interfaces vs ZCA concepts
Hi, On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen faas...@startifact.com wrote: * It'd be nice if __call__ came back with a LookupError instead of a TypeError, but how to get from A to B without breakage? Maybe I've misunderstanding, but what's the advantage of making IFoo(x) raise a LookupError instead of a TypeError? I've tried to follow the thread but I've been confused about this. I do rely on catching TypeErrors quite often in my code -- I had thought it was intended as part of the API. I like that treating it as typecasting instead of lookup blurs the conceptual distinction between adapting x to IFoo and asserting x implements IFoo directly -- when I actually want to know one or the other I can use explicit adaptation or check providedBy. In other words I use IFoo(x) when I don't care whether IFoo(x) == x. I suppose it's not a big deal but catching LookupErrors instead would feel somewhat less semantic for the way I think about this. But from what I've caught of the larger thread it sounds like I'm in the minority here. -Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] dropping Python 2.4 support in the Zope Toolkit?
On Tue, May 5, 2009 at 8:07 AM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: Lennart Regebro wrote: Can you expand on this argument, because I don't understand it. Zope 2.10 doesn't stop working because Zope 2.12 no longer supports Python 2.4. And you are not expected to use Zope Toolkit with Zope 2.10, as Zope 2.10 uses Zope 3.3 rather than Zope Toolkit. - I think that as a principle, dropping support for a Python version that's commonly used in our community, should be a decision that requires a strong argument *for*, not a strong argument *against*. - The Zope Tool Kit aims to be a bridge between our different communities, and possibly other communities that may want to consume Zope software (are all of those using Python 2.5?). That means that those of us who are not in a position to move to Python 2.5+ soon deserve to be heard. Of course, Plone's point of view shouldn't be overriding to other concerns, but see point 1. - If you count the Zope community as those who also maintain Zope 2, we need to recognise that there's been no viable way for Plone to get to Python 2.5 until now, and the other changes in 2.12 mean it's not feasible to upgrade to it in the 3.x series. This is nobody's fault, of course, but it does leave a chasm that'll only widen as time goes on. - Once the ZTK is decreed to no longer need to support Python 2.4, I suspect no new development on the Zope platform will bother with it either. That means users of Plone can't use these packages. That in turn deprives those Zope packages of testers and potential contributors. - We are using Zope 3.4+ packages successfully with Zope 2.10 right now. I don't see that the ZTK will be any different. In fact, ZTK should help here, because we're getting a saner dependency structure. The Plone community is working hard to move to Python 2.5, but reality is we won't get there for another 12-18 months, in part because Zope 2.12 is only now entering alpha and incorporates a lot of other (good!) changes that we need more time to integrate and work out a migration story for. Martin +1 Speaking from the context of my own primary zopey project (Py2.4-only OpenCore, which depends directly on Plone and increasingly on various zope.* packages) and as a user of Plone, I hope that the main-line ZTK would continue to support Py2.4 for a while longer. Announcing a dropping Py2.4 support deadline of, say, a year from now would give those of us still on Py2.4 time to prepare for that future, whether by getting our products onto 2.5 in time, or by gathering together a community to maintain 2.4-compatible versions of the necessary packages. I think that in the medium term, maintaining 2.4 support (at least during a smooth transition period) could theoretically *lower* the ZTK maintenance burden significantly -- for example if the Plone community has the ability to experiment with newer versions of the ZTK or ZTK packages than Zope2, this could provide forward momentum for Zope2's own ZTK dependency as the results of those experiments feed back upstream to Zope2's stable KGS. I know we're talking about unspecified future additions to a still fuzzy set of packages, so, to be as concrete as possible, I've been increasingly hoping to track at least zope.i18n development as closely as possible in OpenCore, using the ZTK/Zope2/Plone KGSes as a baseline rather than a hard requirement. I've been looking forward to trying out other packages in that context as well as the ZTK and dependency unravelling makes casual experimentation easier. egj ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How can I force the language for a particular template rendering?
How about just monkeypatching the active negotiator?
{{{
negotiator = getUtility(zope.i18n.interfaces.INegotiator)
orig = negotiator.getLanguage
negotiator.getLanguage = lambda foo, bar: 'fr'
text = my_page_template()
negotiator.getLanguage = orig
}}}
Haven't tested it, but in my (limited) understanding of the I18N system
something like that ought to work..
egj
On Fri, Apr 17, 2009 at 3:14 PM, Chris Withers ch...@simplistix.co.ukwrote:
Hi All,
What I want to do is best shown in pseudocode:
something.setLanguage('fr')
text = my_page_template()
something.restoreLanguage()
...the reason I want to do this is that the results of that template
will not be in the language negotiated for the current user, as the
result is then emailed to someone who may not be speaking the same
language as them.
I can't find a way to specify a target_language that overrides the
negotiated language into the ZPT rendering process. Is there such a way?
Suggestions welcomed!
Chris
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How can I force the language for a particular template rendering?
Actually -- for a more proper solution -- I believe
zope.i18n.interfaces.IUserPreferredLanguages is expected to adapt a request
(rather than being a contextless utility) so I bet you could register a
custom IUserPreferredLanguages whose getPreferredLanguages returns ['fr'] on
an IForceLanguage interface, and mark the current request with
IForceLanguage before rendering the template.
egj
On Fri, Apr 17, 2009 at 3:35 PM, Ethan Jucovy ethan.juc...@gmail.comwrote:
How about just monkeypatching the active negotiator?
{{{
negotiator = getUtility(zope.i18n.interfaces.INegotiator)
orig = negotiator.getLanguage
negotiator.getLanguage = lambda foo, bar: 'fr'
text = my_page_template()
negotiator.getLanguage = orig
}}}
Haven't tested it, but in my (limited) understanding of the I18N system
something like that ought to work..
egj
On Fri, Apr 17, 2009 at 3:14 PM, Chris Withers ch...@simplistix.co.ukwrote:
Hi All,
What I want to do is best shown in pseudocode:
something.setLanguage('fr')
text = my_page_template()
something.restoreLanguage()
...the reason I want to do this is that the results of that template
will not be in the language negotiated for the current user, as the
result is then emailed to someone who may not be speaking the same
language as them.
I can't find a way to specify a target_language that overrides the
negotiated language into the ZPT rendering process. Is there such a way?
Suggestions welcomed!
Chris
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How can I force the language for a particular template rendering?
Actually -- for a more proper solution -- I believe
zope.i18n.interfaces.IUserPreferredLanguages is expected to adapt a request
(rather than being a contextless utility) so I bet you could register a
custom IUserPreferredLanguages whose getPreferredLanguages returns ['fr'] on
an IForceLanguage interface, and mark the current request with
IForceLanguage before rendering the template.
egj
On Fri, Apr 17, 2009 at 3:35 PM, Ethan Jucovy ethan.juc...@gmail.comwrote:
How about just monkeypatching the active negotiator?
{{{
negotiator = getUtility(zope.i18n.interfaces.INegotiator)
orig = negotiator.getLanguage
negotiator.getLanguage = lambda foo, bar: 'fr'
text = my_page_template()
negotiator.getLanguage = orig
}}}
Haven't tested it, but in my (limited) understanding of the I18N system
something like that ought to work..
egj
On Fri, Apr 17, 2009 at 3:14 PM, Chris Withers ch...@simplistix.co.ukwrote:
Hi All,
What I want to do is best shown in pseudocode:
something.setLanguage('fr')
text = my_page_template()
something.restoreLanguage()
...the reason I want to do this is that the results of that template
will not be in the language negotiated for the current user, as the
result is then emailed to someone who may not be speaking the same
language as them.
I can't find a way to specify a target_language that overrides the
negotiated language into the ZPT rendering process. Is there such a way?
Suggestions welcomed!
Chris
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Mon, Mar 2, 2009 at 9:59 AM, Martijn Faassen faas...@startifact.com wrote: Also, is there any caching for already processed packages in the include finder code? If no, I'd probably like to contribute some, if I'll use z3c.autoinclude. :) Ah, you're thinking in the same direction. I don't think there's any caching at all yet in autoinclude and that'd be the first thing I'd look at if I were to look into speeding it up. It's just I hadn't run into the pain point yet. That's correct, there's no caching yet. I haven't done any profiling but I'm pretty sure that the pain-point algorithm is z3c.autoinclude.utils.dependencyForDottedName. Some sort of caching ought be a huge help there; the function currently iterates over all sys.path entries for each autoincludeDependencies directive found. Specifically my guess is that utils.py's L81-85 is what would benefit most from a cache, because that's where autoinclude actually peers into the sys.path entries to look for packages. I'd really appreciate it if you could work with Dan to get performance data on autoinclude. I'd be happy to! :) Dan, what do you think? The big reason I haven't tried any optimizations yet is that I haven't found a situation with noticeable slowdown that would let me measure any potential optimizations meaningfully, but it sounds like you've already solved that problem. :) So I think the next step would be to reproduce that situation and measure the execution time before and after we add that caching strategy. Or we could just profile the code rather than relying on my guess. Regards, Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Fri, Feb 27, 2009 at 10:35 AM, Martijn Faassen faas...@startifact.com wrote: Hey, On Thu, Feb 26, 2009 at 5:32 PM, Ethan Jucovy ethan.juc...@gmail.com wrote: That's true on paper, but in practice z3c.autoinclude's *indirection* does make a difference when you're just trying to debug what's going on. If something goes wrong, that's true. I'm not sure how it goes wrong - if it goes right, you're going to have included the list of dependencies that's in setup.py (if they have relevant zcml files) At any rate, the next release of z3c.autoinclude will provide this feature, through environment variables: http://lists.plone.org/pipermail/framework-team/2009-February/002690.html Yeah, I saw some code. I don't quite see the point of that feature, as it will most likely result in non-working code, right? Yeah, most likely. :) I'll admit I mainly added it for symmetry with autoincludePlugins, where the case for that feature is a lot stronger, because of the control inversion that happens there. A few months ago Vincent Fretin pointed out (http://mail.zope.org/pipermail/grok-dev/2008-November/006690.html) a possible case for at least selective disabling of dependency autoinclusion, though, and I think the feature is harmless enough that it may as well exist. The only times I've used it so far have been just for fun though -- turning off autoinclusion somewhere to see what breaks. :) Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: merge zc.configuration's exclude directive into zope.configuration.
On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen faas...@startifact.com wrote: Hey, On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev nad...@gmail.com wrote: Yep, I know about z3c.autoinclude, but I don't like it, as it makes things more implicit and it also Yes, automation makes things more implicit. This is *not* an argument that can be used against any and all automation. An explicit includeDependencies directive will include the configure.zcml and meta.zcml of packages that are dependencies of that package. You make less mistakes this way (and it's very common to make the mistake to forget inclusion of some ZCML). It's also pretty rare to want to do otherwise in my experience (and there's always the exclude directive). I'd also argue auto-inclusion can actually help guard against dependency bugs, such as cases where a package tries to include ZCML it doesn't depend on (and works because some other package makes the dependency installed). +1 on Martijn's points (unsurprisingly, as I'm one of his co-authors on autoinclude ;) I'll also add that z3c.autoinclude tries very hard to log its actions in an easily traceable way, and I've been trying to build in more debugging tools as well. slows down startup time for applications that uses many eggs. When claims like that are made, I'd like to see measurements that demonstrate significant slowdowns during startup. Undoubtedly more code is excuted than when you write out 'include' directives manually, but is the slowdown actually measurable? I've heard this claim before and I'd also love to see some measurements. I haven't really had the time to do any myself, and in my experience z3c.autoinclude hasn't slowed things down enough to bother me. But I may have an unusually high tolerance for slow-moving code. :) The slowest code in z3c.autoinclude is well isolated and is tested for many edge cases, and I'm pretty sure there are obvious optimizations that can be made without even rewriting it. So improving the execution speed should be quite easy and safe; it just hasn't been a priority for me, and I'd prefer to get some measurements before trying to tweak it. I'd like to see an option for packages that are using z3c.autoinclude to make autoincluding conditional, so those who doesn't like it or needs more control could just turn it off. That's asking for a feature that other packages that *don't* use autoinclude don't support! You lose control as soon as you include a package's configure.zcml. There's no difference with non-auto-inclusion here; [snip] That's true on paper, but in practice z3c.autoinclude's *indirection* does make a difference when you're just trying to debug what's going on. At any rate, the next release of z3c.autoinclude will provide this feature, through environment variables: http://lists.plone.org/pipermail/framework-team/2009-February/002690.html Regards, Ethan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.autoinclude doesn't include extra_requires
Hey Christian, I finally had a bit of time to sort out my Zope.org SVN credentials and try to look into this ... but I'm actually not getting very far. What I'm stumped on: is there any way to find out which extras have been installed with a package? The details: The bad line is src/z3c/autoinclude/dependency.py#L22: for req in self.context.requires(): (Here self.context is a distribution object, that of the module that wants to includeDependencies. We're about to look for ZCML files in the packages of its dependencies.) The pkg_resources documentation (http://peak.telecommunity.com/DevCenter/PkgResources#distribution-objects) explains: requires(extras=()) List the Requirement objects that specify this distribution's dependencies. If extras is specified, it should be a sequence of names of extras defined by the distribution, and the list returned will then include any dependencies needed to support the named extras. So in other words, L22 should look like: +for req in self.context.requires(extras=list_of_actively_installed_extras_for_the_distribution): The problem is, I can't figure out how to figure out which extras are actively installed. (We don't want to pass in *all* of the distribution's extras, because that might include *uninstalled* extras -- which would mean we end up trying to include ZCML from packages that we should not be, and that might not even be installed.) Thanks, Ethan On Tue, Nov 11, 2008 at 2:58 AM, Christian Zagrodnick [EMAIL PROTECTED] wrote: Hi, when I include an egg with extras (like gocept.foo[server]) the dependencies from the extra are not automatically included with autoinclude. I'm posting this here, because there is no other obvious place (no project for this on lauchpad). Regards, -- Christian Zagrodnick · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Buildout site
On Thu, Jul 17, 2008 at 2:17 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Just FYI, the final resting place for this information will likely be inside a more general documentation website, the address buildout.zope.org is just a temporary resting place. Just to make a discussion Jens and I were having in the background explicit. While it's good if this appears in the Zope stack documentation site, I think it's also important for there being a separate identity for the buildout project. This goes beyond documentation, but also talks about a developer community and invites people to use it in their own projects, as well as contribute. I also think an overview of recipes could be a good part of this. I think a separate website is part of such an identity. Other things that could help establish an identity are things like a logo. I think this is a really fantastic idea. To speak broadly, it's great that you're so mindful of the real importance of identity -- in both a branding sense and simply in the sense of being a self-contained entity -- for the development of software communities and software itself. Buildout is a standalone product independent of the Zope framework or libraries, but that's only meaningful if it actively establishes an independent identity in people's minds. I think you're doing a really great thing for the community by paying attention to these issues. So, in short, thanks. :) Cheers, Ethan Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
