Re: [Zope-dev] ZCA proposal
On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Change that to Martins IFoo.adapter(...) and I'm behind it to. :-) It's more symmetrical with utility, as they are both nouns. But I can survive IFoo.adapt() as well. -- 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] Adapter for class with slots
Hello,
I've stumbled upon a wrinkly edge case (bug?) in zope.component.
What I was trying to do is register an AbsoluteURL adapter for
lovely.remotetask.processor.ProcessorRequest objects, and since they
don't implement a specific interface, I thought I'd use the class
itself as the required component. But registering the adapter for
* lovely.remotetask.processor.ProcessorRequest fails with a strange
TypeError (see below). The reason is that the class inherits from
zope.publisher.base.BaseRequests which uses __slots__.
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)
Which will raise
File
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
line 419, in _getAdapterRequired
elif not ISpecification.providedBy(r):
TypeError: 'member_descriptor' object is not callable
Why is this? Can this be made to work? How would I go about
investigating that?
Thanks,
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 )
Re: [Zope-dev] ZCA proposal
Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Thinking about it a bit, it strikes me that IFoo.adapt(context) may not be right. This reads IFoo adapt context, which doesn't make sense. What I really want to hear is context adapted to IFoo. So maybe it's IFoo.adapting(context)? IFoo.adapterFor(context)? IFoo.adapter(context)? Just thinking out loud. To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. To me, generic names like instance and singleton suggest we're trying to solve some grand problem that would make our brains hurt. I find it more satisfying to solve a more specific problem. I am participating in this thread because I believe the current zope.component API is unnecessarily verbose, hindering readability and adoption by Python projects that would benefit. I think adding adapt() and utility() to zope.interface.Interface might improve the situation. We could instead add adapt() and utility() functions to the zope.component package, but I haven't seen any function signature that would turn out as simple as IFoo.adapt(x). Shane ___ 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 wrote:
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)
Which will raise
File
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
line 419, in _getAdapterRequired
elif not ISpecification.providedBy(r):
TypeError: 'member_descriptor' object is not callable
Why is this? Can this be made to work? How would I go about
investigating that?
It looks to me like a possible bug in zope.interface. Try deleting
_zope_interface_coptimizations.so to hopefully expand that traceback.
Shane
___
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] ZCA proposal
Lennart Regebro wrote: On Thu, Dec 3, 2009 at 03:14, Gary Poster gary.pos...@gmail.com wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) Change that to Martins IFoo.adapter(...) and I'm behind it to. :-) It's more symmetrical with utility, as they are both nouns. But I can survive IFoo.adapt() as well. Yeah, I'm not terribly fussed either way. 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] ZCA summary so far...
Hey, Thanks for doing this summary! Gary Poster wrote: [snip] == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see No consensus section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the tuple multi-adaptation section above. It's clear that a unification of adaptation and utility lookup in the API as I discussed is going much too far for many people. So I've given up on that. (we can always take it up again in some other context in the future) 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] ZCA proposal
Gary Poster wrote: = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. Do you really think introducing tuple adaptation on __call__ is risky? I don't like having two ways to look up an adapter on the interface: __call__() and adapt() = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as look, it's a factory, but, oh well. Progress usually means compromise. I agree, because I think an API like instance() suggest a unification of adapter and utility lookup. :) 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] ZCA proposal
Martin Aspeli wrote: [snip] Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Haven't you been one of the people who has maintained that changing the names would do a disservice to everybody? 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] ZCA proposal
Martijn Faassen wrote: Martin Aspeli wrote: [snip] Thinking out loud further, I think I may actually prefer IFoo.instance() instead of .utility(), but maybe that debate is already passed. .utility() is OK too. Haven't you been one of the people who has maintained that changing the names would do a disservice to everybody? Yeah, yeah, I was just thinking out loud. :) Calling the lookup method instance is not really changing the name: you'd still have utility / to register it etc. It's just the naming of a lookup method, which indicates get me the instance providing this interface. I can see it getting confusing, though. On balance, I think .utility() is better. I'm also not opposed to IFoo() for lookup (so long as registration and documentation maintains the adapter/utility distinction). 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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Wed Dec 2 12:00:00 2009 UTC to Thu Dec 3 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: Wed Dec 2 20:38:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013125.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Dec 2 20:40:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013126.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:42:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013127.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:44:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013128.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:46:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013129.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Dec 2 20:48:22 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-December/013130.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] ZCA proposal
Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. 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] ZCA proposal
For my 2 cents (not that I think anyone should care): +1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw) -1 for tuple adaptation on 1st arg. Besides losing genericity on tuple adaptation, we risk situations where a class could trigger multi-adaptation by inheriting from tuple. +1 for deprecating unamed default argument. Yes, this is separate from the 1st item above but if in the future we want to expand/fix the IFoo() semantics, we should start deprecating things as early as possible. Besides defalt=something is way more readable and explicitly, especially when you consider the typecasting mindset. Cheers, Leo On Thu, Dec 3, 2009 at 10:00, Martijn Faassen faas...@startifact.com wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. Regards, Martijn ___ 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 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] ZCA proposal
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway sh...@hathawaymix.org wrote: To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Agreed. I also like adapt because it is a verb -- which I prefer method names to be. For the same reason I'm not real keen on the name utility... although I can't come up with anything better than get_utility at the moment. Too bad less-than is already defined for interfaces, otherwise we could do something crazy like IFoocontext for single adapters and IFooa, b, c for multiapdapters. I suppose we could do: IFoocontext and IFooa, b, c instead. Somehow I suspect that'll provoke a gag reflex in the most Pythonic among us as well as annoy those that want something googlable for the uninformed code reader. -- Benji York ___ 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] improving the utility and adapter lookup APIs
On Thu, Dec 03, 2009 at 07:44:54AM +0100, Christian Theune wrote: That reminds me that I had the occasional wish to invoke the ZCA using some kind of chaining mechanism so that an adapter can ask for the next less specific adapter that would have been invoked if the former wasn't there. The use case is similar: delegate to a default. Occasionally I've missed a getNextAdapter() call too. 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] zope.testing.testrunner.debug.post_mortem and try/finally
On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote: On 2009-12-2 23:06, Marius Gedminas wrote: On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: Here's another idea: a testrunner option that takes a file name and line number and inserts a breakpoint at that position. That way you can get the same effect as editing the code without actually having to do so. Is that possible? I once spent hours studying pdb docs and found no way to set a breakpoint in advance, without modifying the source file in question, and without having the user to do manual interaction at the beginning. I think mr.freeze (see http://pypi.python.org/pypi/mr.freeze ) can do this. Thank you for the link, this looks very interesting. Perhaps there is some code there you could borrow. Or just depend and invoke it. AFAICS mr.freeze subclasses Pdb and rewires some of its internals in a nontrivial fashion to be able to do that: http://dev.plone.org/collective/browser/mr.freeze/trunk/mr/freeze/freeze.py 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] ZCA proposal
On Wed, Dec 02, 2009 at 09:14:42PM -0500, Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) +1 for this. -1 for IFoo((foo, bar)). 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] ZCA proposal
Martijn Faassen wrote: I was thinking people would get behind the following proposal: IFoo() for adaptation and multi adaptation (with tuple arguments) and IFoo.utility() for utility lookups. One argument in favor of using plain calls for multi adaptation (using tuples) is that people have already discussed various alternative names to 'adapt' in just this little thread... The other argument is that we would avoid too many ways to do it. I would love to eventually have IFoo(x,y) be the equivalent of getMultiAdapter((x,y), IFoo), but I am -1 on using IFoo((x,y)) for this as that would break currently working code. (Not just theoretically, I have code in production that does this). I am +1 on using a __future__+frame hack to get IFoo(x,y) working now, but also +1 on using IFoo.adapt(x,y) or IFoo(some_keyword_arg=(x,y)) if that is more acceptable. Even though I thought we had good consensus on it originally, since then I've seen an argument against a deprecation warning of implicit default on IFoo(). It is a separate discussion. I'd be in favor of it as I think the implicit default argument on IFoo() is not that common (and actually quite hard to read!), but we could easily separate that from this discussion. +1 on deprecating us of the second positional argument as default, even if the signature is otherwise unchanged. It would break the backwards compatibility of adapting a tuple using the adapter hook. I think that's a risk we could take. I disagree, breaking backwards compatibility in this particular way would hurt several projects I am involved in. - Jacob ___ 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] ZCA proposal
Jacob Holm wrote: [snip] I disagree, breaking backwards compatibility in this particular way would hurt several projects I am involved in. Okay, understood. So I'll go with .adapt() and .utility() and deprecate implicit default argument. 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] zope.testing.testrunner.debug.post_mortem and try/finally
On Thu, Dec 03, 2009 at 03:51:06PM +0200, Marius Gedminas wrote: On Thu, Dec 03, 2009 at 08:55:32AM +0100, Wichert Akkerman wrote: On 2009-12-2 23:06, Marius Gedminas wrote: On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: Here's another idea: a testrunner option that takes a file name and line number and inserts a breakpoint at that position. That way you can get the same effect as editing the code without actually having to do so. Is that possible? I once spent hours studying pdb docs and found no way to set a breakpoint in advance, without modifying the source file in question, and without having the user to do manual interaction at the beginning. I think mr.freeze (see http://pypi.python.org/pypi/mr.freeze ) can do this. Thank you for the link, this looks very interesting. Perhaps there is some code there you could borrow. Or just depend and invoke it. Better not, it pulls in too much stuff (WSGI and Zope 2 bits). AFAICS mr.freeze subclasses Pdb and rewires some of its internals in a nontrivial fashion to be able to do that: http://dev.plone.org/collective/browser/mr.freeze/trunk/mr/freeze/freeze.py I've had some success with this: import pdb class SlightlyLessInsanePdb(pdb.Pdb): first_time = True def user_line(self, *a, **kw): if self.first_time: self.set_continue() self.first_time = False else: pdb.Pdb.user_line(self, *a, **kw) def run_with_breakpoint(filename, lineno, func, *args, **kw): dbg = SlightlyLessInsanePdb() dbg.set_break(filename, lineno) return dbg.runcall(func, *args, **kw) 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] zope.testing.testrunner.debug.post_mortem and try/finally
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas mar...@gedmin.as wrote: I've had some success with this: [snip code] Nice. I'd love to see this wired into the testrunner so people could specify breakpoints on the command line while running tests. If no one else gets around to that, I might. One day. -- Benji York ___ 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] ZCA summary so far...
On Dec 3, 2009, at 1:54 AM, Chris McDonough wrote: My $.02 is here: http://www.plope.com/Members/chrism/zca_thoughts_summary I was going to comment on your blog, even though it was separate from the mailing list, but then I couldn't register an account, so here I am. I agree with a decent chunk of what you say. I guess my experiences working with new and casual ZCA users in Launchpad are somewhat similar to your BFG experiences. I'm very interested in working on changes in the underlying registry. Like you (I think), I'd also like to support the ability for using classes and abcs for specs. I have some work in that direction. I also want a better debugging API, which I have also investigated. We might disagree on the specifics, but it sounds like we're similar in broad desires there. I also agree with many of your perceptions of what we have: the experimental package I have started that subsumes the jobs of zope.interface and zope.component is called pluggable, which echoes one of your points. I don't think replacing these packages is a practical way forward, but it helps me think and imagine. I think that moving forward might be easiest to do by making the adapter registry pluggable in zope.interface and zope.component, and working on this in another package.At that point, interested users of zope.interface and zope.component could choose to use our registry (and perhaps it might evolve to become the blessed registry at some point); and we could provide alternative ways of using the package, separate from zope.component and zope.interface. We should collaborate. In my copious spare time I would like to call you and see if you and I can at least agree on some experiments in this direction. I'd like it if my work had some chance of uptake in BFG. I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. Gary ___ 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] internal improvements to zope.component Was: ZCA summary so far...
Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. * I'd like to see some underlying refactorings in zope.component/zope.interface. * I'd also like to see a better registration API * documenting this clearly (and perhaps in advance of any actual work) is important. * I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements. * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. * I *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular. * but I'd be fine if we got a better API and implemented the old APIs on top of these. * and we might eventually deprecate the old APIs. 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] internal improvements to zope.component Was: ZCA summary so far...
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote: Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. I didn't follow this until I squinted at it and came up with I'd like us not to make any API improvements on looking up things dependent on underlying refactorings. That sounds reasonable. * I'd like to see some underlying refactorings in zope.component/zope.interface. A broad agreement, but an agreement nonetheless. * I'd also like to see a better registration API I don't have that pain point ATM, but I can vaguely see where one might. * documenting this clearly (and perhaps in advance of any actual work) is important. +1 on documenting. -1 on not allowing some experiments to happen first. * I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements. +1 * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. I'm +1 on that as long as it can be rephrased to ...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities. * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I am not a fan of design by committee. I do think a community (committee) often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them). * I *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular. I don't have that pain point ATM, but I can vaguely see where one might. * but I'd be fine if we got a better API and implemented the old APIs on top of these. * and we might eventually deprecate the old APIs. Agreed. Gary ___ 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] internal improvements to zope.component Was: ZCA summary so far...
Gary Poster wrote: On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote: Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. I didn't follow this until I squinted at it and came up with I'd like us not to make any API improvements on looking up things dependent on underlying refactorings. That sounds reasonable. Sorry, that wasn't very clear. I just meant that we should improve the lookup API not waiting for underlying API changes to materialize. These processes should be decoupled. If from underlying API changes we come up with even better lookup APIs, so be it. * I'd like to see some underlying refactorings in zope.component/zope.interface. A broad agreement, but an agreement nonetheless. * I'd also like to see a better registration API I don't have that pain point ATM, but I can vaguely see where one might. Where is your pain point? * documenting this clearly (and perhaps in advance of any actual work) is important. +1 on documenting. -1 on not allowing some experiments to happen first. Sure, experiments are fine. * I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements. +1 * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. I'm +1 on that as long as it can be rephrased to ...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities. Sure, we don't want to drop support either. :) * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I don't want zope.component become a shell on some other package with a better API. I know that that's often how we work, but I'd like to try to make zope.component itself that better package. I am not a fan of design by committee. I do think a community (committee) often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them). I don't want this to be a take it or leave it situation. I'd like there to be some commitment to making this package work for the whole community. I do not want this to be another vision that in the end the community can't use because we still depend on zope.component. * I *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular. I don't have that pain point ATM, but I can vaguely see where one might. I think Chris McDonough shares this problem, as he already forked the directive implementations. Probably grokcore.component could be a bit nicer too. 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 )
[Zope-dev] the ZCA API decision
Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] Hopefully we can move forward towards implementation. Thomas Lotze, are you happy enough with this to still help with the implementation? Thanks everybody for your participation in the discussion! 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] internal improvements to zope.component Was: ZCA summary so far...
On Dec 3, 2009, at 12:08 PM, Martijn Faassen wrote: Gary Poster wrote: On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote: Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. I didn't follow this until I squinted at it and came up with I'd like us not to make any API improvements on looking up things dependent on underlying refactorings. That sounds reasonable. Sorry, that wasn't very clear. I just meant that we should improve the lookup API not waiting for underlying API changes to materialize. These processes should be decoupled. If from underlying API changes we come up with even better lookup APIs, so be it. Ah, I see (and I didn't before). Yes. * I'd like to see some underlying refactorings in zope.component/zope.interface. A broad agreement, but an agreement nonetheless. * I'd also like to see a better registration API I don't have that pain point ATM, but I can vaguely see where one might. Where is your pain point? There are many concerns that my interviews raised. I talked about them in my OSCON talk, and they are at the heart of my PyCon talk. You and Chris appear to share somewhere between many and all of them, between you. I don't have time for more details than that right now. ... * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. I'm +1 on that as long as it can be rephrased to ...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities. Sure, we don't want to drop support either. :) My point is that I don't find net value in the names, especially adaptation, as I've said repeatedly. I don't want them to be necessary in lower-level APIs that I teach and promote. I'm happy to continue to have internals that can *support* APIs that use the adapter names. I don't want them to *use* those names. The confusion in message here I think is because of your next point, on which we disagree. * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I don't want zope.component become a shell on some other package with a better API. I know that that's often how we work, but I'd like to try to make zope.component itself that better package. I don't think we are at a point that debating this is worthwhile, at least from my perspective. I still want to see what of my own pain points I can remove, without the constraint you describe. I'll be better able to debate (or concede!) once I have done that. I am not a fan of design by committee. I do think a community (committee) often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them). I don't want this to be a take it or leave it situation. I'd like there to be some commitment to making this package work for the whole community. I do not want this to be another vision that in the end the community can't use because we still depend on zope.component. If the community *can't* use my work, then it is wasted. I don't want that. I want it to be valuable. I especially want Launchpad to be able to use it easily, and we use a lot of Zope community packages. That said, it's a risk one takes on projects like this sometimes. I'll try to mitigate it. Gary ___ 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] the ZCA API decision
Martijn Faassen wrote: Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] A general +0 from me, because it seems to be 99% bw compat and does no harm. - C ___ 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] ZCA proposal
Am 03.12.2009, 14:18 Uhr, schrieb Benji York be...@zope.com: Agreed. I also like adapt because it is a verb -- which I prefer method names to be. For the same reason I'm not real keen on the name utility... although I can't come up with anything better than get_utility at the moment. I've been struggling with this as well. I think the linguistic quandary is similar to the adapter/utility (non-)unification stuff. There is great value in saying that method names *should* be verbs. Alternatives might be IFoo.return() (is this doable?) IFoo.issue() (like library books), or IFoo.use() (because I can't bring myself to use utilise) However, there is probably more value in consistency with the terms as used in the API. It's been a very interesting discussion for me as I don't spend that much time coding. Regarding introducing non-zopers to this stuff: I've found that both Philip von Weiterhausen and Martin Aspeli do make this stuff easier to understand assuming you've got some kind of application context. But we do need to evangelise this stuff better! @Chris - Are you referring to the interface specification/marker duality? If so, I agree that this is definitely a conceptual pothole and most of the use I've seen is of interfaces as markers (smartcards). Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] the ZCA API decision
Martijn Faassen wrote: Thomas Lotze, are you happy enough with this to still help with the implementation? I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future. How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first? -- 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 )
Re: [Zope-dev] the ZCA API decision
On Dec 3, 2009, at 3:33 PM, Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze, are you happy enough with this to still help with the implementation? I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future. How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first? I don't know if too much experimentation is needed for this in particular. I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations. I would be comfortable with you leading the effort, in a shared branch, if that works for you. You could specify what parts you wanted help on. Or would you prefer someone else to take charge? Gary ___ 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] the ZCA API decision
Martijn Faassen wrote: Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed. [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] Hopefully we can move forward towards implementation. Thomas Lotze, are you happy enough with this to still help with the implementation? Thanks everybody for your participation in the discussion! Regards, Martijn -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be ___ 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] the ZCA API decision
Godefroid Chapelle wrote: I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed. AFAICT, the decision to reject or postpone that has been postponed. :-) Shane ___ 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] the ZCA API decision
Gary Poster wrote: I don't know if too much experimentation is needed for this in particular. I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations. I would be comfortable with you leading the effort, in a shared branch, if that works for you. You could specify what parts you wanted help on. Or would you prefer someone else to take charge? I'd be happy to lead this effort, if you like to put it like that. I wouldn't want to take it out of Martijn's hands, though, unless he's happy with it as well, given that he's the one who started the discussion. As for any technical questions, it's too late in the night over here now for me to say anything serious, so I'll reply to that tomorrow. -- 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 )
Re: [Zope-dev] the ZCA API decision
Martijn Faassen wrote: Hi there, I think we've had enough discussion to make a decision. I'm a little worried that neither Stephan Richter, nor Jim Fulton have had much weight in on this. They seem like important stakeholders. :) Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. +1 A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. +1 On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). +1 [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] I'd give them a week or so at least... this is deep stuff. ;) Hopefully we can move forward towards implementation. Thomas Lotze, are you happy enough with this to still help with the implementation? Thanks everybody for your participation in the discussion! Can we all get back to our lives now? :-) 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] the ZCA API decision
Martin Aspeli wrote: Can we all get back to our lives now? :-) FWIW, I try to participate in discussions like these by reading and writing only short emails. I find that I don't miss much that way. Life is more enjoyable without essay-mails. Shane ___ 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] the ZCA API decision
Shane Hathaway wrote: Martin Aspeli wrote: Can we all get back to our lives now? :-) FWIW, I try to participate in discussions like these by reading and writing only short emails. I find that I don't miss much that way. Life is more enjoyable without essay-mails. You don't know me very well, apparently... ;-) Martin 'verbose' Aspeli -- 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] the ZCA API decision
On Thu, Dec 03, 2009 at 03:11:07PM -0700, Shane Hathaway wrote: Godefroid Chapelle wrote: I tried to follow this discussion closely: however, I cannot say that I understand if doing multi-adaptation with IFoo(bar, baz, boo) has been rejected or postponed. AFAICT, the decision to reject or postpone that has been postponed. :-) While taking steps now to soften the backwards compatibility issues for that future decision. -- Brian Sutherland ___ 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] the ZCA API decision
On Thu, Dec 03, 2009 at 06:41:03PM +0100, Martijn Faassen wrote: Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). FWIW, I'm +1 as well. -- Brian Sutherland ___ 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 )
