Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

improving the utility and adapter lookup APIs

  

 
First page Previous page 1 2 3 Next page Last page  View All Zope dev RSS feed   Index | Next | Previous | View Threaded


faassen at startifact

Nov 25, 2009, 7:41 AM

Post #1 of 51 (1836 views)
Permalink
improving the utility and adapter lookup APIs
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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


benji at zope

Nov 25, 2009, 8:01 AM

Post #2 of 51 (1783 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
<faassen [at] startifact> 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 [at] zope
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 )


tl at gocept

Nov 25, 2009, 8:17 AM

Post #3 of 51 (1783 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


gary.poster at gmail

Nov 25, 2009, 8:17 AM

Post #4 of 51 (1781 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


matthew at matthewwilkes

Nov 25, 2009, 8:17 AM

Post #5 of 51 (1783 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


gary.poster at gmail

Nov 25, 2009, 8:20 AM

Post #6 of 51 (1777 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


tl at gocept

Nov 25, 2009, 8:34 AM

Post #7 of 51 (1775 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


gary.poster at gmail

Nov 25, 2009, 8:45 AM

Post #8 of 51 (1776 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


chrism at plope

Nov 25, 2009, 8:54 AM

Post #9 of 51 (1772 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


gary.poster at gmail

Nov 25, 2009, 9:03 AM

Post #10 of 51 (1775 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


chrism at plope

Nov 25, 2009, 9:09 AM

Post #11 of 51 (1778 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


tseaver at palladion

Nov 25, 2009, 10:27 AM

Post #12 of 51 (1775 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benji York wrote:
> On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
> <faassen [at] startifact> 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 [at] palladion
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-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


tseaver at palladion

Nov 25, 2009, 10:29 AM

Post #13 of 51 (1777 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
-----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 [at] palladion
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-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


tseaver at palladion

Nov 25, 2009, 10:34 AM

Post #14 of 51 (1773 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
-----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 [at] palladion
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-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


kobold at kobold

Nov 25, 2009, 11:51 AM

Post #15 of 51 (1778 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
* 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 [at] zope
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 )


marius at gedmin

Nov 25, 2009, 12:19 PM

Post #16 of 51 (1778 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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
Attachments: signature.asc (0.19 KB)


brian at vanguardistas

Nov 25, 2009, 12:32 PM

Post #17 of 51 (1765 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


tseaver at palladion

Nov 25, 2009, 12:52 PM

Post #18 of 51 (1767 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
-----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 [at] palladion
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-----

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


hanno at hannosch

Nov 25, 2009, 1:17 PM

Post #19 of 51 (1767 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver <tseaver [at] palladion> 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 [at] zope
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 )


faassen at startifact

Nov 25, 2009, 1:21 PM

Post #20 of 51 (1765 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


me at rpatterson

Nov 25, 2009, 1:54 PM

Post #21 of 51 (1765 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
Marius Gedminas <marius [at] gedmin> 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 [at] zope
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 )


dev at projekt01

Nov 25, 2009, 6:01 PM

Post #22 of 51 (1758 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
> 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 [at] zope
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 )


tl at gocept

Nov 25, 2009, 10:39 PM

Post #23 of 51 (1734 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )


ws at gocept

Nov 25, 2009, 11:07 PM

Post #24 of 51 (1736 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
* 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 [at] startifact> [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 [at] palladion> [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 [at] kobold> [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 [at] zope
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 )


faassen at startifact

Nov 26, 2009, 1:48 AM

Post #25 of 51 (1730 views)
Permalink
Re: improving the utility and adapter lookup APIs [In reply to]
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 [at] zope
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 )

First page Previous page 1 2 3 Next page Last page  View All Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.