Re: [Zope-dev] Bootstrapping ZCA for Python 3.
And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/ If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Generations in Zope 2
Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? Regards, -- Christian Zagrodnick · c...@gocept.com 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 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] Generations in Zope 2
On Tue, Dec 15, 2009 at 11:02, Christian Zagrodnick c...@gocept.com wrote: Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? Not really, but by making it a part of Five you make any use of generations dependant on having at least that version of Five. If that's OK for you, then no objections. The alternative would be a separate production but admittedly, having a separate product just to register single-line adapter seems silly. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] Generations in Zope 2
On 12/15/09 11:02 , Christian Zagrodnick wrote: Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? -1, this would add a needless dependency on zope.app.generations to Zope 2 as far as I can see. Why not move include this in zope.app.generations itself in a [zope2] extra ? Or create a tiny five.generations package to do this. Wichert. ___ 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] Generations in Zope 2
On Tue, Dec 15, 2009 at 11:20, Wichert Akkerman wich...@wiggy.net wrote: -1, this would add a needless dependency on zope.app.generations to Zope 2 as far as I can see. Good point. The lack of imports tricked me into thinking this was easier than it was. :) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ 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] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Dec 14 12:00:00 2009 UTC to Tue Dec 15 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Dec 14 20:38:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013197.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Dec 14 20:40:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013198.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 14 20:42:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013199.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 14 20:44:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013200.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 14 20:46:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013201.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Dec 14 20:48:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013202.html ___ 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] Generations in Zope 2
On 2009-12-15 11:20:19 +0100, Wichert Akkerman wich...@wiggy.net said: On 12/15/09 11:02 , Christian Zagrodnick wrote: Hi, to get generations working in Zope 2 the following subscriber is needed: @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent) def evolve_minimum(event): zope.app.generations.generations.evolve( Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM) I think should become part of Zope 2 / Five. Objections? -1, this would add a needless dependency on zope.app.generations to Zope 2 as far as I can see. Why not move include this in zope.app.generations itself in a [zope2] extra ? Or create a tiny five.generations package to do this. five.generations is part of five enough for me ;) I don't like an zope2 extra for zope.app.generations. -- Christian Zagrodnick · c...@gocept.com 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 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] Bootstrapping ZCA for Python 3.
On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote: And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/ If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-) How about virtualenv? svn checkout svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk zc.buildout cd zc.buildout virtualenv tmp tmp/bin/easy_install zope.testing tmp/bin/python setup.py develop cd zc.recipe.egg_ ../tmp/bin/python setup.py develop cd ... tmp/bin/zope-testrunner --test-path=src When I tried this on Python 2.6 I got some failures, e.g. Expected: ... warning: install_lib: 'build/lib' does not exist -- no Python modules to install Got: ... warning: install_lib: 'build/lib.linux-i686-2.6' does not exist -- no Python modules to install and Expected: ... UserError: Couldn't install: nonexisting.tgz Got: ... File /home/mg/src/zc.buildout/src/zc/buildout/easy_install.py, line 360, in _call_easy_install if d.project_name != dist.project_name: AttributeError: 'str' object has no attribute 'project_name' and a few more. If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout bin/test) and see if I get the same failures. Cheers! Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ 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] Bootstrapping ZCA for Python 3.
On 12/15/09 2:21 PM, Marius Gedminas wrote: If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout bin/test) and see if I get the same failures. Be sure to look at DEVELOPERS.txt in the root (you need pythons without setuptools and you need to run with -c dev.cfg if memory serves me). Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ 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] Adapter for class with slots
* Wolfgang Schnerring w...@gocept.com [2009-12-07 08:53]:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
I'll try and see whether I can come up with a way for zope.interface to
do the Right Thing(tm) in this situation.
I forgot to mention this here: the edge case has been fixed and released
in zope.interface-3.5.3
Wolfgang
___
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] Interfaces vs ZCA concepts
So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas ___ 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] zc.recipe.wrapper 1.0.1
Hi all, I just re-released zc.recipe.wrapper. The previous release lacked a corresponding svn tag. This release fixes that, and should be otherwise unremarkable. -- Alex Smith Software Engineer Zope Corporation ___ 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] Bootstrapping ZCA for Python 3.
On Tue, Dec 15, 2009 at 14:21, Marius Gedminas mar...@gedmin.as wrote: On Tue, Dec 15, 2009 at 10:22:03AM +0100, Lennart Regebro wrote: And now it's zc.buildout. It also uses itself, to set up the environment so that you can test it. I did try using distribute instead, but I get strange inconsistent errors, different ones each time I try. :-/ If someone can set up a way of running the tests for zc.buildout without using zc.buildout, I'm sure I can help port it to Python 3, but for now I give up. :-) How about virtualenv? I don't see how that helps. But in any case it's not ported to Python 3 yet afaik. svn checkout svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk zc.buildout cd zc.buildout virtualenv tmp tmp/bin/easy_install zope.testing tmp/bin/python setup.py develop cd zc.recipe.egg_ ../tmp/bin/python setup.py develop cd ... tmp/bin/zope-testrunner --test-path=src When I tried this on Python 2.6 I got some failures, e.g. I do not get a zope-testrunner or even a bin directory when doing this. On Tue, Dec 15, 2009 at 14:38, Reinout van Rees rein...@vanrees.org wrote: On 12/15/09 2:21 PM, Marius Gedminas wrote: If I weren't extremely hungry and starving, I'd run the tests in the official fashion (bin/buildout bin/test) and see if I get the same failures. Be sure to look at DEVELOPERS.txt in the root (you need pythons without setuptools and you need to run with -c dev.cfg if memory serves me). I have, and it says to run python dev.py. Dev py import zc.buildout. That fails, as zc.buildout isn't ported to Python 3 yet. This is the same bootstrapping problem I had with setuptools (who uses itself to install/build itself) and zope.testing (who uses it's own testrunner to run the tests). For setuptools we fixed it by an ugly hack that means 2to3 is run on all of setuptools as soon as you run setup.py. For zope.testing I made a custom test command for setuptools that creates a test-script in the temp directory manually, and then calls it, which is possibly a slightly less ugly hack. Possibly that last trick might work for zc.buildout too, I haven't investigated. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ 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] Interfaces vs ZCA concepts
Am Dienstag 15 Dezember 2009 17:16:12 schrieb Thomas Lotze: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? Conceptually, this sounds a lot like what I was thinking when I read the discussion, a week or two ago. So I am very much like the idea - to let an interface be an interface without bringing it into tight coupling to other zope-concepts. So the remaining question is, how to implement this in a clean way and still keeping the usage simple and readable. Something like IFoo.do.adapt(x,y) and IFoo.do.get_utility() (as well as IFoo.do.something_completely_different() ) would be possible, but somewhat unusual ... Mat ___ 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] Interfaces vs ZCA concepts
Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute that isn't provided by zope.interface itself. For example: IFoo.adapter(bar, default=baz) Would be the almost the same as: getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz) That is unless getInterfaceAttribute(IFoo, 'adapter') returned the passed-in marker which would instruct zope.interface to raise an AttributeError instead. In turn, zope.component could then provide a getInterfaceAttribute() implementation that called: getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') Yes, the first parameter above is the original interface. The IInterfaceMethod is an interface defining __call__(*args, **kw) This idea would also allow one to define named adapters for IInterfaceMethod to, for instance, __call__ or __add__, such that the semantics of IFoo(...) or IFoo + IBar could also be changed. Perhaps entry points could be used to provide getInterfaceAttribute implementations, and if multiple entry points are present, each would be called in turn to attempt to provide the attributes of an interface, but maybe this is too much flexibility... Just an idea... Cheers, Leo On Tue, Dec 15, 2009 at 14:16, Thomas Lotze t...@gocept.com wrote: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas ___ Zope-Dev maillist - zope-...@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
Re: [Zope-dev] Interfaces vs ZCA concepts
Hey, Good to see there's progress! Thomas Lotze wrote: [snip] Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a ComponentLookupError? I was thinking we should keep the behavior as close to zope.component as we can, including ComponentLookupError. Don't you get a ComponentLookupError with the classic adapter hook too? So I'm -1 to making this a TypeError. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). I think a monkey patch would be fine. Opinions about making it more structured: * have dummy implementations in zope.interface that raise NotImplementedError * have that NotImplementedError say to look for implementations in zope.component * have the docstring of these methods also talk about zope.component * have the docstring on the methods that are injected be clear that they are being injected into zope.interface That way someone reading the zope.interface code can at least find out that this functionality is injected from zope.component. [as an aside it'd be interesting to find out how much of of zope.component functionality could sensibly make it into zope.interface, but that's another project; Gary Poster has some ideas in relation to this] In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? I'm +1 on this general approach. Implementation in zope.component, and inject it into zope.interface during import time. I'm still sneakily hoping that in a few years we'll be able to get calling the interface be the one true way of looking up implementations of that interface (utilities and adapters and whatnots), but we'll see. Did you make an implicit 'default' deprecated on __call__ yet by the way? Regards, Martijn ___ 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] Interfaces vs ZCA concepts
I wonder if maybe something like (notionally): class InterfaceBase(object): @classmethod def add_more_api(cls, **kw): cls.__dict__.update(kw) - C Leonardo Rochael Almeida wrote: Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute that isn't provided by zope.interface itself. For example: IFoo.adapter(bar, default=baz) Would be the almost the same as: getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz) That is unless getInterfaceAttribute(IFoo, 'adapter') returned the passed-in marker which would instruct zope.interface to raise an AttributeError instead. In turn, zope.component could then provide a getInterfaceAttribute() implementation that called: getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') Yes, the first parameter above is the original interface. The IInterfaceMethod is an interface defining __call__(*args, **kw) This idea would also allow one to define named adapters for IInterfaceMethod to, for instance, __call__ or __add__, such that the semantics of IFoo(...) or IFoo + IBar could also be changed. Perhaps entry points could be used to provide getInterfaceAttribute implementations, and if multiple entry points are present, each would be called in turn to attempt to provide the attributes of an interface, but maybe this is too much flexibility... Just an idea... Cheers, Leo On Tue, Dec 15, 2009 at 14:16, Thomas Lotze t...@gocept.com wrote: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas
Re: [Zope-dev] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leonardo Rochael Almeida wrote: Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute that isn't provided by zope.interface itself. For example: IFoo.adapter(bar, default=baz) Would be the almost the same as: getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz) That is unless getInterfaceAttribute(IFoo, 'adapter') returned the passed-in marker which would instruct zope.interface to raise an AttributeError instead. In turn, zope.component could then provide a getInterfaceAttribute() implementation that called: getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') Yes, the first parameter above is the original interface. The IInterfaceMethod is an interface defining __call__(*args, **kw) This idea would also allow one to define named adapters for IInterfaceMethod to, for instance, __call__ or __add__, such that the semantics of IFoo(...) or IFoo + IBar could also be changed. Perhaps entry points could be used to provide getInterfaceAttribute implementations, and if multiple entry points are present, each would be called in turn to attempt to provide the attributes of an interface, but maybe this is too much flexibility... Just an idea... I had originally contemplated replacing the current adapter hook with a more generic hook: the __call__ of interface would delegate to this hook for its semantics. Given that the choice to use __call__ is not widely enough accepted, I think something like your solution makes sense. I'm not sure that hooking __getattr__ is going to be performant enough, but a similar mechanism probably could be made fast enough. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksoDpQACgkQ+gerLs4ltQ4LkACgxb9GzzGU7RAnj9rTEhJMVnJ9 iVwAniefCS8HXGyEiSxG7V7fYWJISsrZ =bmx9 -END PGP SIGNATURE- ___ 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] SVN: zopetoolkit/trunk/ztk.cfg Include distribute, so we can use it in presence of the allow-picked-versions=false
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Log message for revision 106536: Include distribute, so we can use it in presence of the allow-picked-versions=false Changed: U zopetoolkit/trunk/ztk.cfg -=- Modified: zopetoolkit/trunk/ztk.cfg === --- zopetoolkit/trunk/ztk.cfg 2009-12-15 15:33:38 UTC (rev 106535) +++ zopetoolkit/trunk/ztk.cfg 2009-12-15 15:41:19 UTC (rev 106536) @@ -250,6 +250,7 @@ # Dependencies: ClientForm = 0.2.10 +distribute = 0.6.10 docutils = 0.5 infrae.subversion = 1.4.5 Jinja2 = 2.1.1 I'm not so sure that we want to push distribute into the ZTK dependencies: can you explain that more clearly? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksoEpUACgkQ+gerLs4ltQ6qEQCglYkPT3Fu3+VIEJyub1C4nNbJ RJQAn1uaf4uIJMLhCjmKD2CqPENGHBhI =jyl9 -END PGP SIGNATURE- ___ 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] Interfaces vs ZCA concepts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a ComponentLookupError? I was thinking we should keep the behavior as close to zope.component as we can, including ComponentLookupError. Don't you get a ComponentLookupError with the classic adapter hook too? So I'm -1 to making this a TypeError. +1 to TypeError: nobody really cares about the type of the error: code that wants to be robust about a failure uses the 'query' methods. As long as the message is informative enough (which ComponentLookupError isn't, really) we should be fine. If we made CLE derive from TypeError, we could even still be satisfying the contract. zope.component raises TypeError if you can't adapt. It raises ComponentLookupError it can't find a utility. Not so: see $ZSVN/zope.component/trunk/src/zope/component/registry.py: class Components: ... def getUtility(self, provided, name=u''): utility = self.utilities.lookup((), provided, name) if utility is None: raise ComponentLookupError(provided, name) return utility ... def getAdapter(self, object, interface, name=u''): adapter = self.adapters.queryAdapter(object, interface, name) if adapter is None: raise ComponentLookupError(object, interface, name) return adapter which matches the contract spelled out in the docstrings for IComponent. That class raises TypeError only for invalid values passed to the various registration functions. At any rate, we are talking about errors raised from zope.itnerface APIs, which nowhere mention or use CLE:: $ svn info . | grep URL URL: svn+ssh://svn.zope.org/repos/main/zope.interface/trunk $ svn up At revision 106615. $ find . -name *.py | xargs grep ComponentLookupError $ Nobody calling an interface today has any *defined* behavior to expect in the case of failure (in fact, '__call__' is not even part of IInterface!) Let's keep exceptions the same. People do catch specific errors, so those who've done 'except TypeError' now aren't going to be happy if we change that to something else when they try to move to use the new API. Please point to existing code which calls 'IFoo.utility(name=bar)' and catches a CLE. Since this is a new API we are talkign about, there can't be any BBB concerns. Any code today which wants a utility is calling 'getUtilty' (if it *knows* the utility must be registered) or 'queryUtility' (if it thinks it might not be). Less facetiously than my first challenge: please point to actual code in the wild which looks like:: try: foo = getUtilty(IFoo, name='bar') except ComponentLookupError: # do something instead of:: foo = queryUtility(IFoo, name='bar') if foo is None: # do something I will argue that any code doing the first, outside of maybe tests of the ZCA itself is plain broken. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksoWyUACgkQ+gerLs4ltQ4dCQCfeF5a1xYdWNIJtnh/fVoeBbHt g1cAoKRzg8utmIYpK5skXhk2qhhJ/qR0 =BKnt -END PGP SIGNATURE- ___ 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] Interfaces vs ZCA concepts
Tres Seaver wrote:
+1 to TypeError: nobody really cares about the type of the error: code
that wants to be robust about a failure uses the 'query' methods. As
long as the message is informative enough (which ComponentLookupError
isn't, really) we should be fine. If we made CLE derive from TypeError,
we could even still be satisfying the contract.
zope.component raises TypeError if you can't adapt. It raises
ComponentLookupError it can't find a utility.
Not so: see $ZSVN/zope.component/trunk/src/zope/component/registry.py:
I'm pretty sure you get a TypeError when Zope can't adapt. I'm not sure
where it's thrown from, though.
Stupid example:
from plone.portlets.interfaces import IPortletType
class X(object): pass
...
x = ()
IPortletType(x)
Traceback (most recent call last):
File console, line 1, in module
TypeError: ('Could not adapt', (), InterfaceClass
plone.portlets.interfaces.IPortletType)
class Components:
...
def getUtility(self, provided, name=u''):
utility = self.utilities.lookup((), provided, name)
if utility is None:
raise ComponentLookupError(provided, name)
return utility
...
def getAdapter(self, object, interface, name=u''):
adapter = self.adapters.queryAdapter(object, interface, name)
if adapter is None:
raise ComponentLookupError(object, interface, name)
return adapter
getAdapter() is different, though:
from zope.component import getAdapter
getAdapter(x, IPortletType)
Traceback (most recent call last):
File console, line 1, in module
File
/Users/optilude/.buildout/eggs/zope.component-3.7.1-py2.6.egg/zope/component/_api.py,
line 98, in getAdapter
raise ComponentLookupError(object, interface, name)
ComponentLookupError: ((), InterfaceClass
plone.portlets.interfaces.IPortletType, u'')
which matches the contract spelled out in the docstrings for IComponent.
That class raises TypeError only for invalid values passed to the
various registration functions.
Something else is raising TypeError then. :)
At any rate, we are talking about errors raised from zope.itnerface
APIs, which nowhere mention or use CLE::
Ok.
$ svn info . | grep URL
URL: svn+ssh://svn.zope.org/repos/main/zope.interface/trunk
$ svn up
At revision 106615.
$ find . -name *.py | xargs grep ComponentLookupError
$
Nobody calling an interface today has any *defined* behavior to expect
in the case of failure (in fact, '__call__' is not even part of IInterface!)
Let's keep exceptions the same. People do catch specific errors, so
those who've done 'except TypeError' now aren't going to be happy if we
change that to something else when they try to move to use the new API.
Please point to existing code which calls 'IFoo.utility(name=bar)' and
catches a CLE. Since this is a new API we are talkign about, there
can't be any BBB concerns.
True, but we're also going to ask people to change their use of
getUtility(IFoo) to IFoo.utility and ditto for adaption. If I have
existing code that looks like this:
try:
foo = IFoo(bar)
except TypeError:
pass
I would like to be able to move that mechanically to:
try:
foo = IFoo.adapt(bar)
except TypeError:
pass
If I have to change the exception type in any of the scenarios (utility
lookup would be similar) then that would be another change to detect,
and possibly a harder one to spot in less contrived code.
Any code today which wants a utility is calling 'getUtilty' (if it
*knows* the utility must be registered) or 'queryUtility' (if it thinks
it might not be). Less facetiously than my first challenge: please
point to actual code in the wild which looks like::
try:
foo = getUtilty(IFoo, name='bar')
except ComponentLookupError:
# do something
instead of::
foo = queryUtility(IFoo, name='bar')
if foo is None:
# do something
I will argue that any code doing the first, outside of maybe tests of
the ZCA itself is plain broken.
Perhaps, but I'm pretty sure people have done this. They may also have
done it in tests.
I'm not religious about it, but I think that if we're only changing the
API, it'd be preferable not to change the exceptions we throw unless
semantics also change.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
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] Interfaces vs ZCA concepts
Martijn Faassen wrote: * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a ComponentLookupError? I was thinking we should keep the behavior as close to zope.component as we can, including ComponentLookupError. Don't you get a ComponentLookupError with the classic adapter hook too? So I'm -1 to making this a TypeError. The ComponentLookupError is defined by zope.component. So the only way of getting a CLE raised by Interface.adapt or Interface.utility would be to call the non-query-style lookup functions from the zope.component API and let the error propagate. The current implementation of the new interface methods pretend, however, to allow for more hookability than just calling a zope.component function, so it is intentional to not let any error propagate but defer to the next hook instead and raise an exception of a type known to zope.interface (i.e. not CLE) if none of the hooks succeeds. The choice of TypeError was made in analogy with __call__. Currently, you get a TypeError if IFoo(bar) fails while zope.component.getAdapter(bar, IFoo) raises CLE. IMO, the clean way to solve this is to drop the analogy with the __call__ implementation and no longer try to cater for generic `adapt` and `utility` behaviour. Together with avoiding a direct dependency of zope.interface on zope.component, this leads to injecting non-hookable implementations of `adapt` and `utility` from zope.component itself. I think a monkey patch would be fine. Opinions about making it more structured: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and those of named components and lookup contexts if the methods were to be specified by IInterface. * have that NotImplementedError say to look for implementations in zope.component I would actually like a mechanism that doesn't care about what package will inject which pieces of API. Do you think such generality is asking too much (at least at this point in time)? * have the docstring on the methods that are injected be clear that they are being injected into zope.interface Of course. That way someone reading the zope.interface code can at least find out that this functionality is injected from zope.component. IMO, we should mention this as a usage example but not as a requirement. [as an aside it'd be interesting to find out how much of of zope.component functionality could sensibly make it into zope.interface, but that's another project; Gary Poster has some ideas in relation to this] I think before doing such a thing, we should come up with a precise definition of which concepts are the concern of interfaces, which are that of the ZCA and exactly where to draw the line. Anything else looks IMO dangerously like a slippery slope towards mixing it all up into zope.interface. I'm still sneakily hoping that in a few years we'll be able to get calling the interface be the one true way of looking up implementations of that interface (utilities and adapters and whatnots), but we'll see. Me too. Did you make an implicit 'default' deprecated on __call__ yet by the way? Not yet; the other issue looked more interesting so far ;o) BTW, that parameter isn't even called 'default' but 'alternate' in Interface.__call__. The very name of the default argument is another thing that is sneaking from zope.component into zope.component. -- Thomas ___ 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] Compression format for ZTK packages
Hi, Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? PEP 8: A Foolish Consistency is the Hobgoblin of Little Minds Regards, Baiju M ___ 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] Compression format for ZTK packages
On 2009-12-16 08:35, Baiju M wrote: Hi, Most of the source distribution packages of ZTK are in .tar.gz format. But there are few exceptions. For consistency, can we use .tar.gz format for all releases ? Once there is a python 2.4 release which fixes the tarfile bug, or once python 2.4 support is officially no longer desirable. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Interfaces vs ZCA concepts
On 12/15/2009 11:32 PM, Tres Seaver wrote: Given that the choice to use __call__ is not widely enough accepted, I think something like your solution makes sense. I'm not sure that hooking __getattr__ is going to be performant enough, but a similar mechanism probably could be made fast enough. That sounds a lot like what the SQLAlchemy guys did with their attrgetter (well, that was 2007 IIRC so they might be doing something even more fun by now. Just in case someone goes for hunting down a fast pluggable __getattr__-alike. -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
