Hi there, Reading the thread Chris McDonough started (and ended) about modifying the way utility registration works reminded me of the following thinking. It's quite independent and probably even antithetical to Chris's approach as it uses interfaces, but that's fine. The goal is to make it easier to look up certain componenty things. The goal is to have to import from "zope.component" as little as possible for lookups. Just import interfaces and you'll be done. I think it makes sense to make the lookup operation disappear into the "language" as much as we can make them. I know we've had this kind of discussion before, but let's get something working this time around. So I'm also looking for volunteers to help out with the implementation. I'm going to ignore registration APIs for now in this discussion. While they can be improved too, we have ZCML and martian-style registration systems that can handle that ok. Let's focus on lookup APIs first. We have a nice way to look up a single adapter: from foo import IFoo IFoo(object) Unfortunately, this breaks down when you want to look up a multiadapter: from foo import IFoo from zope import component component.getMultiAdapter((x, y), IFoo) That's an extra import and a lot more typing. We also have it break down when you want to look up a utility: from zope import component component.getUtility(IFoo) So let's look at ways to hook this up to interfaces. Adapter: IFoo(x) Adapter with default: IFoo(x, default=default) So far it's all supported. (I think. It's hard to find the code that supports this.. hints?) Named adapter: IFoo(x, name='something') Multiadapter: IFoo.multi(x, y) Multiadapter with default: IFoo.multi(x, y, default=default) Named multiadapter: IFoo.multi(x, y, name='something') Utility: IFoo.utility() [or possibly IFoo() instead?] Utility with default: IFoo.utility(default=default) [or IFoo(default=default)?] Named utility: IFoo.utility(name='something') [or IFoo(name='something')?] 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 I know Jim had some objections towards implementation of this in an earlier discussion, but later changed his mind. So I'm going to look at Jim for hints about implementing this. :) If we do well we might all have this for Christmas. :) Thoughts? Regards, Martijn
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen <faassen@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
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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
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... Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Marius Gedminas <marius@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...
Similarly, I've often sub-classed built-in types when using the ZCA such that isinstance(obj, tuple) is True. Ross
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes <matthew@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
On Thu, Nov 26, 2009 at 14:34, Benji York <benji@zope.com> wrote:
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes <matthew@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
On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
On Thu, Nov 26, 2009 at 14:34, Benji York <benji@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
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 <leorochael@gmail.com> wrote:
On Thu, Nov 26, 2009 at 14:34, Benji York <benji@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benji York wrote:
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen <faassen@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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
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
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
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
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
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
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
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
Chris McDonough wrote:
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).
The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module. It would be useful to split these core mechanics into a separate package. Here's why: - The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery. - The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security. - The registry itself is useful outside the context of the zope.component API package; the API is essentially just "candy" on top of the registry itself. I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency). After that's done, I'd suggest we make zope.component depend on zope.registry. At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app. Thoughts? - C
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote:
Chris McDonough wrote:
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).
The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module.
It would be useful to split these core mechanics into a separate package. Here's why:
- The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery.
- The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security.
- The registry itself is useful outside the context of the zope.component API package; the API is essentially just "candy" on top of the registry itself.
I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency).
After that's done, I'd suggest we make zope.component depend on zope.registry.
At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app.
Thoughts?
FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this. Gary
Chris McDonough wrote:
Chris McDonough wrote:
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).
The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module.
It would be useful to split these core mechanics into a separate package. Here's why:
- The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery.
- The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security.
- The registry itself is useful outside the context of the zope.component API package; the API is essentially just "candy" on top of the registry itself.
I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency).
After that's done, I'd suggest we make zope.component depend on zope.registry.
At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app.
One of my first responses would be some worry about zope.component growing a *new* dependency. The goal of zope.component is that it's one of those packages with only a few... I'm trying to see who would be using zope.registry for what exactly. Would it be much harder to experiment with these new APIs on top of zope.component? You'll get a bit more baggage, but the minimal dependency story should be quite small already. I'd rather get some of the additional dependencies (that have a lot to do with supporting ZCML) out of it, instead of moving its core functionality out. You factored various related things together - perhaps it would make sense to do this refactoring within zope.component? I'm +1 on making zope.event part of zope.component and deprecating zope.event. Speculating, would it instead make sense to move zope.registry functionality into zope.interface? The only additional dependency is zope.event. At first glance the answer would be "no" as it really introduces various component architecture concepts... Regards, Martijn
Martijn Faassen wrote:
Chris McDonough wrote:
Chris McDonough wrote:
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). The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module.
It would be useful to split these core mechanics into a separate package. Here's why:
- The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery.
- The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security.
- The registry itself is useful outside the context of the zope.component API package; the API is essentially just "candy" on top of the registry itself.
I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry
It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency).
After that's done, I'd suggest we make zope.component depend on zope.registry.
At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app.
One of my first responses would be some worry about zope.component growing a *new* dependency. The goal of zope.component is that it's one of those packages with only a few...
I'm trying to see who would be using zope.registry for what exactly. Would it be much harder to experiment with these new APIs on top of zope.component? You'll get a bit more baggage, but the minimal dependency story should be quite small already. I'd rather get some of the additional dependencies (that have a lot to do with supporting ZCML) out of it, instead of moving its core functionality out.
I guess this was just a way of trying to draw a line between "the component architecture" (and the conceptual baggage which surrounds it) and useful machinery that currently is hidden inside of it that really should have a life of its own. It's obviously not the only way to do that. It tries to address the following problem. Currently people seem to get wrapped around the axle and confused by the purpose of "the ZCA", which currently implies at least two different things: - Machinery to perform complex registrations and lookups using interfaces in the form of a registry. - A global API that presents a view of the world: "there are these things called utilities and adapters, and this API is how you do adaptation and utility lookup". These two things are conceptually distinct. It shouldn't be necessary to need to understand the concept of "utility" and "adapter" to use a registry. A registry is just machinery that uses interfaces as registration markers for the benefit of later arbitrary lookups, not necessarily just for "finding utilities" or "finding and calling adapter factories". For instance, you might use the registry to register some callable that accepts *no* arguments with, say, two "requires" arguments. You shouldn't need to call this an "adapter", because it's not one; you just want to register something and get it back when you ask nicely. The API of a registry should be able to evolve separately from the API of its consumers (the global ZCA API is only one consumer). The current registry API permits the concepts of utility and adapter to bleed into the implementation, but this needn't be the case forever. We could provide (and document) a very simple registry base class with a normalized API that didn't have any of this conceptual baggage; it would be extremely popular, I think. Likewise, it should be possible to use a different registry implementation to service the ZCA global API. This is possible right now via getSiteManager.sethook, of course.
You factored various related things together - perhaps it would make sense to do this refactoring within zope.component?
I'm +1 on making zope.event part of zope.component and deprecating zope.event.
Speculating, would it instead make sense to move zope.registry functionality into zope.interface? The only additional dependency is zope.event. At first glance the answer would be "no" as it really introduces various component architecture concepts...
It might make sense to me to put a very simple component registry in zope.interface: it already has the concept of "adapter" baked in. - C
Chris McDonough wrote: [snip]
It tries to address the following problem.
Currently people seem to get wrapped around the axle and confused by the purpose of "the ZCA", which currently implies at least two different things:
- Machinery to perform complex registrations and lookups using interfaces in the form of a registry.
- A global API that presents a view of the world: "there are these things called utilities and adapters, and this API is how you do adaptation and utility lookup".
These two things are conceptually distinct.
It shouldn't be necessary to need to understand the concept of "utility" and "adapter" to use a registry. A registry is just machinery that uses interfaces as registration markers for the benefit of later arbitrary lookups, not necessarily just for "finding utilities" or "finding and calling adapter factories". For instance, you might use the registry to register some callable that accepts *no* arguments with, say, two "requires" arguments. You shouldn't need to call this an "adapter", because it's not one; you just want to register something and get it back when you ask nicely.
Agreed, but isn't this registry in zope.interface already? I mean zope.interface.adapter.AdapterRegistry? I've used this for the "not-really-adapting-as-I-don't-want-to-call" in a library of mine recently (traject). You factored out the registry functionality, but there are still plenty of references to utilities in it, for instance. As far as I understand it that would be putting too much into zope.registry already?
The API of a registry should be able to evolve separately from the API of its consumers (the global ZCA API is only one consumer). The current registry API permits the concepts of utility and adapter to bleed into the implementation, but this needn't be the case forever. We could provide (and document) a very simple registry base class with a normalized API that didn't have any of this conceptual baggage; it would be extremely popular, I think.
Likewise, it should be possible to use a different registry implementation to service the ZCA global API. This is possible right now via getSiteManager.sethook, of course.
You factored various related things together - perhaps it would make sense to do this refactoring within zope.component?
I'm +1 on making zope.event part of zope.component and deprecating zope.event.
Speculating, would it instead make sense to move zope.registry functionality into zope.interface? The only additional dependency is zope.event. At first glance the answer would be "no" as it really introduces various component architecture concepts...
It might make sense to me to put a very simple component registry in zope.interface: it already has the concept of "adapter" baked in.
Yeah, I think this makes more sense. So, we have a number of projects: * interface API - the stuff around calling interface I sketched out elsewhere. I think this is relatively low-hanging fruit. On the other hand it breaks backwards compatibility. I wouldn't want this project to depend on the other improvements, and I don't think it has to, so I'd like to see this as zope.component 4.0. * improving and move code that's general enough from zope.component into zope.interface. What this would look like I'm not quite sure about yet, as zope.registry at first glance contains a lot of knowledge about utilities and such still. There are backwards compatibility issues surrounding persistence but hopefully less around the APIs themselves. * an improved registration API for zope.component. This would affect a lot of code that does registration. Documentation projects should go along with all of those. Regards, Martijn
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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
* 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
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 · ct@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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
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 )
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
-----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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver <tseaver@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
Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver <tseaver@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
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver <tseaver@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
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 <tseaver@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
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 Seaver<tseaver@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 · ct@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
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
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
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
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
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
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
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
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 · ct@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
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
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
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
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
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.
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
* 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 <faassen@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 <tseaver@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 <kobold@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
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 <faassen@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 <tseaver@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 <kobold@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
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
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
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
On Wed, Nov 25, 2009 at 16:41, Martijn Faassen <faassen@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
participants (21)
-
Benji York -
Brian Sutherland -
Chris McDonough -
Christian Theune -
Fabio Tranchitella -
Gary Poster -
Hanno Schlichting -
Lennart Regebro -
Leonardo Rochael Almeida -
Marius Gedminas -
Martijn Faassen -
Martin Aspeli -
Matthew Wilkes -
Matthias Lehmann -
Roger -
Ross Patterson -
Shane Hathaway -
Thomas Lotze -
Tim Hoffman -
Tres Seaver -
Wolfgang Schnerring