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] improving the utility and adapter lookup APIs
On 11/30/2009 10:05 AM, Brian Sutherland wrote: On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seavertsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. 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. Christian -- 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 )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. Hanno ___ 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 ) -- 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] improving the utility and adapter lookup APIs
On Nov 30, 2009, at 4:05 AM, Brian Sutherland wrote: On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. I'd argue what you have is pretty obscure though--that is, reading your code example, I'd have to stare at it a while to figure out why it works, and I know the component machinery pretty well. The IDefaultPublishTraverse thing would be inelegant but much more readable. I'd want to think about this class of use cases harder if it were regarded as an important one. I am myself somewhat interested in being able to turn off the short-circuit behavior explicitly if desired. That said, for multiadapters involving more than one required object, IMO the short-circuit behavior should never be invoked. It is not clear that the first object is the one that should be checked for already providing the desired interface. Therefore, in this particular usage, ``IPublishTraverse(self, request)`` would do what you want. 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] improving the utility and adapter lookup APIs
Tim Hoffman wrote: Just re-inforcing this I almost never do IFoo. adaption as I am almost always using multiadapters and utilities so I completely forget about the IFoo adaption capability. Which means I always just write getAdapter as well as it seems more consistent to from an api consumption point of view. I use the IFoo(x) to invoke an adapter (and IFoo(x, None) lookup for a fallback) a *lot*. As in, virtually in every piece of (Zope) software I write. I've also encouraged people to do that in at least three major pieces of documentation (including my book). Similarly, answering a different part of this thread: I use custom adapter factories from time to time, and have documented them as useful practice. Normally, that's because I want to look up the adapter implementation from someplace else than the global registry (e.g. plone.portlets fishes a persistent object out of an annotation at one point), or because I want the ability to abort the annotation by returning None (plone.behavior does that - actually, plone.behavior is a good example of the former also). 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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 16:41, Martijn Faassen faas...@startifact.com wrote: As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass Yuck! That said, it would be easy to implement (haha) if people really want in together with @implemeter(IFoo) Which I have to say I prefer. If we do well we might all have this for Christmas. :) Time to clean up that branch of zope.interface I have, I see. :) -- 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] improving the utility and adapter lookup APIs
Chris McDonough wrote: Martijn Faassen wrote: Hey, Christian Theune wrote: [snip] Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Just as a data point, I forgot to hook adapter_hook in BFG (and I still haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even though lots of folks who use BFG also use the ZCA global API. I'm not implying that this means it's not useful or convenient for old hands. But the old hands don't really need it. Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? I really have trouble remembering the lookup APIs in zope.component myself. People in my experience actually *try* to do multi adaptation using the IFoo adapter hook and then get confused because it fails. If the primary goal is to increase adoption, I think further abstraction of stuff behind nicer calling conventions won't help improve matters: people really need to understand the A-through-Y concepts before they can jump to Z; promoting Z before better explaining A-through-Y first will only add more confusion. We currently do a pretty poor job of explaining A-Y, at least in all the documentation I've read. I think this implies that we need to break down the concepts into more consumable layers and document each of them before we add more abstraction. (as I said elsewhere): My primary goal here is to improve life for those already using the APIs. But I agree we should definitely improve documentation for it too as we go along, and I will help with that. [I think there are decent explanations of at least adaptation floating around, but not along with zope.component, and important bits such as utilities are probably underdocumented] 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Just as a data point, I forgot to hook adapter_hook in BFG (and I still haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even though lots of folks who use BFG also use the ZCA global API. I'm not implying that this means it's not useful or convenient for old hands. But the old hands don't really need it. Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? It's hard to know. No application written using BFG can use the IFoo() pattern at all, and no one complained. The only generalization I can take away from that is that anyone who has written a BFG app and also used the ZCA APIs did not care about the IFoo() pattern. That's maybe not a really useful generalization, because many BFG apps don't use the ZCA APIs at all. - 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] improving the utility and adapter lookup APIs
Just re-inforcing this I almost never do IFoo. adaption as I am almost always using multiadapters and utilities so I completely forget about the IFoo adaption capability. Which means I always just write getAdapter as well as it seems more consistent to from an api consumption point of view. T Interesting. If you mostly do multi-adaptation (and utility lookups) you won't notice it as we know multi adaptation cannot be done with the adapter hook. Was this the case? I really have trouble remembering the lookup APIs in zope.component myself. People in my experience actually *try* to do multi adaptation using the IFoo adapter hook and then get confused because it fails. ___ 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
Am Mittwoch 25 November 2009 17:54:53 schrieb Chris McDonough: Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). - C I haven't been involed in the discussion so far and probably there are already enough colors for the bike shed in the game - anyway, I just want to add my 2 Cent: As has been pointed out, the semantics for adapters and utilities are a bit different: adapters are called on lookup, utilities are just returned. Maybe, it would be a good thing to convey this difference in the lookup-API, like: IFoo(x) - adapt x to IFoo - which means lookup adapter and call it IFoo.get() - return IFoo-Utility - which mean to simply lookup and return utility This makes the semantic difference clear and allows for the (unusual, but maybe still valid) usecase of just returning an adapter for something without automatically calling it: IFoo.get(x) I don't remember when, but I think I once even had a use-case, where I wanted some Utility-like thing, which is not a singleton but a factory. That use-case would also be supported with: IFoo() Best regards, Matthias ___ 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
Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I think if we deprecate the getAdapter API entirely by making it unnecessary, we'd not need to change it either. 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] improving the utility and adapter lookup APIs
Hey, Christian Theune wrote: [snip] Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Anyway, doing the API we want shouldn't be too difficult. So let's assume we have that almost out of the way and let's start talking about making backwards compatibility work. from zope.component.future import __new_interface_semantics__ :)? 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] improving the utility and adapter lookup APIs
On Thu, Nov 26, 2009 at 11:09:35AM -0500, Benji York wrote: On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). Nope, it hadn't occurred to me. Some other argument name could be used instead. Why do you need an argument when you can wrap the tuple in a tuple? IFoo((my_tuple, )) This is what people currently have to do when they use Here's an object I know nothing about: %r % (obj, ) (Personally, I find that ugly and always use text: %s % repr(obj)) While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. I'd rather have the common case (of adapting a non-tuple) be the simpler form and the exception (adapting a tuple) require more verbiage. That would be fine if you always knew what objects you were adapting. Now, to be safe, you always have to use the special verbose syntax in generic code. -1 for making generic code ugly. 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Hey, Christian Theune wrote: [snip] Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) I'd be in favor of an API based off calling the interface directly for everything *if* we can come up with a backwards compatibility story somehow. Just as a data point, I forgot to hook adapter_hook in BFG (and I still haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even though lots of folks who use BFG also use the ZCA global API. I'm not implying that this means it's not useful or convenient for old hands. But the old hands don't really need it. If the primary goal is to increase adoption, I think further abstraction of stuff behind nicer calling conventions won't help improve matters: people really need to understand the A-through-Y concepts before they can jump to Z; promoting Z before better explaining A-through-Y first will only add more confusion. We currently do a pretty poor job of explaining A-Y, at least in all the documentation I've read. I think this implies that we need to break down the concepts into more consumable layers and document each of them before we add more abstraction. - 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] improving the utility and adapter lookup APIs
Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. Sure. But if we want to retain backwards compatibility we'll have to go another 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] improving the utility and adapter lookup APIs
Wolfgang Schnerring wrote:
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure
*why* it must be ruled out. (...or does it, really?)
I'm thinking that this...
* Martijn Faassen faas...@startifact.com [2009-11-25 22:21]:
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
is a valid argument, while this...
* Tres Seaver tsea...@palladion.com [2009-11-25 13:34]:
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
is not, as evidenced by...
* Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]:
IFoo(x, y, default=None, name='something')
or am I missing something here?
I think the problem would exist if we did something like this:
def IFoo(default, name, *args):
pass
but if we did something like this we should be okay, I think:
def IFoo(*args, **kw):
name = kw.get('name', missing)
default = kw.get('default', missing)
adapted = args
So I'm thinking, there is no technical reason that prevents Thomas'
spelling, and I'm wondering, do we really have to preserve backwards
compatibility for this case?
I'm not very fond of the second argument interpreted as default. If it
weren't there I'd be quite interested in the API you're proposing.
But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan code.
We could perhaps release a special version of
zope.interface/zope.component that *forbids* the second argument to see
what bugs pop up, but that'd still not guarantuee we catch all cases.
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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Thomas Lotze wrote: You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. Understood. If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. Sure. But if we want to retain backwards compatibility we'll have to go another way. Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. My favourite option under these circumstances would be something like IFoo.query(*args, default=None, ...) though possibly with a method name in a different color of bike shed, where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may be written as IFoo.query(x, y). -- 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: But someone needs to think of a feasible upgrade scenario. We could instrument all calls to IFoo and see whether a default argument is in use, but what then? I'd be hard to distinguish a default argument from one we're meant to adapt. I'd also be non-trivial to scan code. Here is an interface decorator I intend to try out soon. It adds convenient component lookup methods to a particular interface without requiring any changes to zope.interface. --- (snip) --- from zope.interface.interfaces import IInterface from zope.component import getAdapter from zope.component import getMultiAdapter from zope.component import getUtility from zope.component import queryAdapter from zope.component import queryMultiAdapter from zope.component import queryUtility def componentlookup(iface): Decorator: adds zope.component lookup methods to an interface. Adds utility([default], [name]) and adapt(*args, [default], [name]). assert IInterface.providedBy(iface) def utility(**kw): if 'default' in kw: return queryUtility(iface, **kw) else: return getUtility(iface, **kw) iface.utility = utility def adapt(*args, **kw): if len(args) == 1: # simple adapter lookup arg = args[0] if not 'name' in kw and iface.providedBy(arg): # The object passed in already provides this interface, # and no adapter name was provided, so return the object # unchanged. return arg if 'default' in kw: return queryAdapter(arg, iface, **kw) else: return getAdapter(arg, iface, **kw) # multi-adapter lookup if 'default' in kw: return queryMultiAdapter(args, iface, **kw) else: return getMultiAdapter(args, iface, **kw) iface.adapt = adapt return iface --- (snip) --- Example usage: @componentlookup class IFoo(Interface): pass class Foo(object): implements(IFoo) IFoo.adapt(Foo()) IFoo.adapt(Foo(), HTTPRequest(), name='edit') IFoo.adapt(Foo(), name='x') IFoo.adapt(Foo(), default=None) IFoo.utility(default=None) I think class decorators were added in Python 2.6, but in earlier Pythons you can do this instead: class IFoo(Interface): pass componentlookup(IFoo) 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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) While this would be a multi-adapter lookup: IFoo(my_tuple) -- 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, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. Cheers, Leo ___ 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, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). Nope, it hadn't occurred to me. Some other argument name could be used instead. While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. I'd rather have the common case (of adapting a non-tuple) be the simpler form and the exception (adapting a tuple) require more verbiage. -- 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
Shane Hathaway wrote: [I talk about backwards compatibility issues with some proposed API changes, but this modification doesn't have this issue] Here is an interface decorator I intend to try out soon. It adds convenient component lookup methods to a particular interface without requiring any changes to zope.interface. Cool! It'd be cool if this could be released as a package. I would still propose folding this into zope.component (somehow) and making interfaces do this by default. This is because the decorator as far as I understand requires one to be in control of the interface. 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] improving the utility and adapter lookup APIs
Thomas Lotze wrote: [snip] Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. That was my original proposal, right? (I only propose adding a 'name' argument to the IFoo() lookup if it isn't there already, otherwise it's all new methods). My favourite option under these circumstances would be something like IFoo.query(*args, default=None, ...) though possibly with a method name in a different color of bike shed, where IFoo.query(x) is equivalent to IFoo(x) but a multiadapter lookup may be written as IFoo.query(x, y). It could indeed be done as a single method. See Shane's post for a possible implementation. 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Thomas Lotze wrote: [snip] Then let me suggest not changing the call signature of an interface at all but only add one or a few new methods. Firstly, this will keep backwards compatibility even with code that adapts a tuple, and secondly, it allows us to implement a simple and consistent API anyway. That was my original proposal, right? (I only propose adding a 'name' argument to the IFoo() lookup if it isn't there already, otherwise it's all new methods). I specifically wanted to suggest not adding that name argument but leaving the existing call untouched. I think once we add a new method, we shouldn't at the same time improve the existing one as that would IMO suggest rather forcefully that there's more than one way to do the same thing; just leaving it in there for compatibility is bad enough from the point of view of a clean API. -- 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] improving the utility and adapter lookup APIs
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote: * 2009-11-25 19:35, Tres Seaver wrote: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I'm probably saying something very stupid... What's wrong with the it? Can't we define something like: def __call__(self, *args, **kw): to get a multi adapter in this way? IFoo(x, y, default=None, name='something') That's what I thought of as well. The __call__ signature isn't as expressive as before with that but I'm relatively sure it's a valid implementation of Thomas' suggestions. Tres? -- 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 )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On 11/26/2009 10:48 AM, Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I like the interface being called to be the motion of doing anything with the CA that doesn't expose the CA mechanics to application developers as much. The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? True. It's indeed a goal, as I'd like to be able to use this sooner rather than later. If we break backwards compatibility then we'd have to go through all the IFoo() calls everywhere in all our code to see whether a default argument is in use. Another option would be to provide a backwards-compatibility mode of our code which can be switched on and off. Your notion of bringing the component lookup mechanics closer to being a language feature is very intriguing and I like it a lot. However, if we do so, I'd like us to not having to resort to second-best spelling/implementation due to backwards compatbility. I'd like to work pretty hard on doing the implementation we want because it's a good implementation and then make backwards compatibility work. (I know, I'm a dreamer ...) Christian -- 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 )
Re: [Zope-dev] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote:
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very stupid... What's wrong with the it?
Can't we define something like:
def __call__(self, *args, **kw):
to get a multi adapter in this way?
IFoo(x, y, default=None, name='something')
That's what I thought of as well. The __call__ signature isn't as
expressive as before with that but I'm relatively sure it's a valid
implementation of Thomas' suggestions.
Tres?
Two issues:
- - The proposed spelling weakens documentation / enforceabiliy of the
contract ('**kw' doesn't tell you what the allowed keys are, and in
fact implies that you can pass arbitrary keys).
- - It's backward-incompatible: there are cases in the wild using
'default' as a positional parameter.
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
iEYEARECAAYFAksPgY0ACgkQ+gerLs4ltQ5X9QCdF7X3safMgFuofqjQuOiFfUS+
eEgAn0PbN3cNNdoYiuZh5h86AyXwnP7m
=mdBp
-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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: [snip good stuff] Multiadapter: IFoo.multi(x, y) I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) Multiadapter with default: IFoo.multi(x, y, default=default) Expanding the above: IFoo((x,y), default=default) Utility: IFoo.utility() [or possibly IFoo() instead?] I like IFoo(). As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass We already have the function decorator zope.interface.implementer, I'd extend that notion: @IFoo.implementer class Foo(object): pass If we do well we might all have this for Christmas. :) /me pens a letter to Zanta Claus. -- 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 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? Matt ___ 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 Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote: ... Thoughts? FWIW, this mirrors some of the thoughts I've had, after a lot of discussions with Launchpad/Canonical engineers about the pros and cons of the Zope interface and component code. My OSCON presentation touched on some of these discussions, observations and ideas. Ideas on addressing the problems in the feedback are the focus of my upcoming PyCon presentation. I'm in the middle of an experiment to modify the code without backwards compatibility concerns, to see where it takes me. Obviously, there's an extremely high hurdle for backwards incompatibility, but it was the experiment I wanted to pursue, and one that (obviously) I felt had merit. My intent is to show these at PyCon and start a discussion about the value of the changes, what could be done without breaking backwards compatibility, what could be done with minimal backwards compatibility breakage, and if anything I discovered merits more significant breakage. I'd prefer to think about these myself for a while, and continue to experiment. I've already digested a lot of feedback, from the interviews at Launchpad and Canonical, from past mailing list discussions, from documents like BFG's design defence (http://docs.repoze.org/bfg/1.1/designdefense.html), and from personal discussions. Most people have heard some variation of the (perceived/real) problems before; I'm not ready to settle on my preferred solutions myself. I'm seeing how everything fits together, and it's a big puzzle to assemble. My experiments don't need to hold anyone else up, of course, but I do have a concrete deadline to deliver something. :-) I'll share once I feel that I am reasonably happy with my choices, which may or may not be significantly before PyCon. If other folks want to run on without me, I can at least point to the slides for the OSCON talk I gave with the Canonical/Launchpad feedback if you are interested. 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] improving the utility and adapter lookup APIs
Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. -- 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning 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] improving the utility and adapter lookup APIs
Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. I do think, however, that this is more a problem with registration than with look-up. You need to know whether to register a factory or an instance of a component, but whatever you look up will provide the interface you require and doesn't have to be called in either case. -- 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote: Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. 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] improving the utility and adapter lookup APIs
Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). - 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] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote: Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). Yeah, this is one of my goals too. 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] improving the utility and adapter lookup APIs
Chris McDonough wrote: There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). I realize this might be too abstract. Let me provide an example. Zope views accept (context, request) in their arglist: class AView(object): def __init__(self, context, request): pass This makes sense for Zope, because in a Zope system, the context is almost always important. It usually represents persistent data, or at least the subject of the view. But in other systems, you might want to adapt on a context but not require people to put it in the argument list of the adapter, e.g. if you want to support a request-only calling convention for the adapter ala: def view(request): pass ... and have the user be able to get at the context via request.context. The only way to do this currently is something like the following: provides = map(providedBy, (context, request)) view_callable = registry.adapters.lookup( provides, IView, name=view_name, default=None) request.context = context response = view_callable(request) This is actually fine by me, it works great, but it's not very obvious what's happening to the casual reader. getMultiAdapter should probably be have been named callMultiAdapter, and getMultiAdapter should have just returned the thing. Too late for that now, but it helps explain my original comment. - 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] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: [snip good stuff] Multiadapter: IFoo.multi(x, y) I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) +1 Multiadapter with default: IFoo.multi(x, y, default=default) Expanding the above: IFoo((x,y), default=default) +1 again. Utility: IFoo.utility() [or possibly IFoo() instead?] I like IFoo(). +1 (I argued for this spelling ages ago, like maybe 2002). As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass We already have the function decorator zope.interface.implementer, I'd extend that notion: @IFoo.implementer class Foo(object): pass +0 here: I don't mind the current pattern, but it might be needful to switch to support Lennart's / MvL's work on porting to Python 3. 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 iEYEARECAAYFAksNdwYACgkQ+gerLs4ltQ5MOQCeNsA1pDP2o9xnJp7w/axU4xaI 2HYAniCBpRY0TxV7BBkN6ad5Dtfg49kl =ySiv -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] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. 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 iEYEARECAAYFAksNd4UACgkQ+gerLs4ltQ6+2gCcC1nsuHkvLHimLWvuXutREduQ rSYAnRNRep5iZVbpJqz0W/D3FQKoJwwP =vHqM -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] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. It doesn't matter *to the caller* how the adapter / utility lookup works, which is why making the spelling regular for the caller is a good idea. The caller doesn't know any different in the zope.component API: getUtility(IFoo) getAdapter(context, IFoo) They are both lookups, from the caller's perspective. Why should the caller care that the adapter lookup finds a factory and calls it, while the utility lookup (typically) finds a global singleton? 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 iEYEARECAAYFAksNeLcACgkQ+gerLs4ltQ6F9gCfXooovAG8fAKZtxL06++hPP/9 8H4AoITGogG8Mv4rg2M/FR1cyyOUZwFk =b2h1 -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] improving the utility and adapter lookup APIs
* 2009-11-25 19:35, Tres Seaver wrote: IFoo() IFoo(x) IFoo(x, y) You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. I'm probably saying something very stupid... What's wrong with the it? Can't we define something like: def __call__(self, *args, **kw): to get a multi adapter in this way? IFoo(x, y, default=None, name='something') Best regards, Fabio ___ 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 Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote: Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. I am, in fact, adapting tuples for what I consider to be a good reason (pretty-printing arbitrary objects) in zodbbrowser. http://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/annotate/head:/src/zodbbrowser/value.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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) This also doesn't allow you to use this (anti?)pattern: class Foo: implements(IFoo) def do_something(self): # custom behaviour here default_foo_adapter = getAdapter(self, IFoo) return default_foo_adapter.do_something() # fallback to default behaviour It may not be very theoretically correct, but it's something I find very useful when writing IPublishTraverse implementing classes for zope.publisher to traverse over. It saves me from having to inherit from the default traverser. -- 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] improving the utility and adapter lookup APIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Sutherland wrote: On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) This also doesn't allow you to use this (anti?)pattern: class Foo: implements(IFoo) def do_something(self): # custom behaviour here default_foo_adapter = getAdapter(self, IFoo) return default_foo_adapter.do_something() # fallback to default behaviour It may not be very theoretically correct, but it's something I find very useful when writing IPublishTraverse implementing classes for zope.publisher to traverse over. It saves me from having to inherit from the default traverser. Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't:: $ bin/virtualenv-2.6 --no-site-packages /tmp/brian ... $ cd /tmp/brian $ bin/easy_install zope.component ... $ bin/python from zope.interface import Interface from zope.interface import implements class IFoo(Interface): ... pass ... from zope.component import getAdapter class Foo: ... implements(IFoo) ... foo = Foo() IFoo(foo) is foo True getAdapter(foo, IFoo) is foo Traceback (most recent call last): File stdin, line 1, in module ... zope.component.interfaces.ComponentLookupError: (__main__.Foo instance at 0xb7d0690c, InterfaceClass __main__.IFoo, u'') which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. 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 iEYEARECAAYFAksNmQIACgkQ+gerLs4ltQ7vgQCgyJqce5aMgNksSziaz8oBis1x ZpUAoKcVmJxbIY0gHw4L39wxaV1jbW9T =E7Cn -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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. Hanno ___ 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
Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. 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] improving the utility and adapter lookup APIs
Marius Gedminas mar...@gedmin.as writes: On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote: Matthew Wilkes wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? I would agree that its completely spurious: I can't imagine wanting that. I prefer the regularity in Benji's spelling over satisfying a non-existing usecase. I am, in fact, adapting tuples for what I consider to be a good reason (pretty-printing arbitrary objects) in zodbbrowser. http://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/annotate/head:/src/zodbbrowser/value.py Similarly, I've often sub-classed built-in types when using the ZCA such that isinstance(obj, tuple) is True. Ross ___ 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
Hi all Betreff: Re: [Zope-dev] improving the utility and adapter lookup APIs On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. Of corse do adapter adapt something. But why do we excpect that we will get an adapter if we enhance the interface implementation and do some dance with e.g. IFoo(???). Form the interface point of view there should only be a contract that the returned object provides that interface. Adapters and utilities are different, that's no question. But if an interfaces get called without an argument, it could return an object providing this interface. Based on the missing value (not None, just missing) the object doesn't get adapted/called and could return an utility. If we skip this option, then IFoo() will raise a ComponentLookupError or tell us that the signature at least needs one or more argument. The following makes sense to me: getUtility(IFoo) - IFoo() getUtility(IFoo, name='foo') - IFoo(name='foo') getAdapter(obj, IFoo) - IFoo(obj) getMultiAdapter((foo, bar), IFoo) - IFoo(foo, bar) Regards Roger Ineichen 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 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
Martijn Faassen wrote: Thomas Lotze wrote: [snip] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) The last one won't work if we want to maintain backwards compatibility. The second argument is the default. Technically, that's obvious. I guess I meant to say How about... then. You didn't explicitly mention the subject of backwards compatibility in your original message, so let's make it explicit now: Is backwards compatibility a goal in this discussion? If it isn't, I'm rather against an API that interprets an argument to IFoo() as meaning different things depending on whether it's a tuple or not. Python itself has an API that works like this (string formatting) and is moving away from it. Requiring the default to be specified as a named argument would also help readability IMO. -- 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] improving the utility and adapter lookup APIs
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I quite like the simplicity of this spelling, so I want to be sure *why* it must be ruled out. (...or does it, really?) I'm thinking that this... * Martijn Faassen faas...@startifact.com [2009-11-25 22:21]: The last one won't work if we want to maintain backwards compatibility. The second argument is the default. is a valid argument, while this... * Tres Seaver tsea...@palladion.com [2009-11-25 13:34]: You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. is not, as evidenced by... * Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]: IFoo(x, y, default=None, name='something') or am I missing something here? So I'm thinking, there is no technical reason that prevents Thomas' spelling, and I'm wondering, do we really have to preserve backwards compatibility for this case? 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 )
