[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: We were discussion a (notional) value adapter, whose factory would have the contract of returning an object of a specific concrete type, rather than on implementing an interface. Right, but the CA supports the use of classes instead of interfaces and that works just fine here... There are reasonable usecases for such adapters, but the CA machinery doesn't permit registering them: it requires that the 'provided' argument be either an interface or None (although the 'required' args can be concrete types). Nah, for both provides and adapts classes can be used in place of interfaces just fine, and I've got this working just how I want it now :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Dieter Maurer wrote: As Chris example demonstrates, it would have been better to call IZopeDublinCore(myobj) the IZopeDublinCore adaptation of myobj. Agreed, and would have saved me a lot of confusion. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Tres Seaver wrote: We were discussion a (notional) value adapter, whose factory would have the contract of returning an object of a specific concrete type, rather than on implementing an interface. Right, but the CA supports the use of classes instead of interfaces and that works just fine here... There are reasonable usecases for such adapters, but the CA machinery doesn't permit registering them: it requires that the 'provided' argument be either an interface or None (although the 'required' args can be concrete types). Nah, for both provides and adapts classes can be used in place of interfaces just fine, and I've got this working just how I want it now :-) This doctest blows up on my machine when run against the Zope3 trunk: from zope.component import getAdapter from zope.component import provideAdapter from zope.interface import Interface from zope.interface import implements class IFoo(Interface): ... pass class Foo(object): ... implements(IFoo) foo = Foo() def get_a(x): ... return 'a' def get_b(x): ... return 'b' provideAdapter(get_a, adapts=(IFoo,), provides=str, name='a') provideAdapter(get_b, adapts=(IFoo,), provides=str, name='b') getAdapter(object=foo, interface=str, name='a') 'a' getAdapter(object=foo, interface=str, name='b') 'b' The first 'provideAdapter' call raises an exeption because 'str' doesn't have an '__iro__'. The second *doesn't* raise, because the code which raised the first exception leaves an artifact in a module global. Bot lookups fail with 'ComponentLookupError'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXbz6+gerLs4ltQ4RAhbKAJ9nIr2GI3MPNygbmNuqiPmYLU5aLwCgxv5G pb6cW4/y9gjzQdN5nDuz6kQ= =Os0S -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Not sure what official terminology glossary you're basing this on, but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. Whatever is called to instantiate that object we call the adapter factory or adapter implementation. The whole zope.component API (both registration and lookup) reflects this use of the terminology. Right, I see where you're coming from now, and I have to agree with Dieter. IZopeDublinCore(myobj) is not an adapter. It is an instance of the adapter or the adapted object, depending on your point of view. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: IZopeDublinCore(obj) is a flexible version of ZDCAnnotatableAdapter(obj) Flexible, because a different implementation that ZDCAnnotatableAdapter might be used. That's dispatched through the adapter registry. Right, exactly. IZopeDublinCore(myobj) does an adapter lookup based on the type of 'myobj' That's the lookup in the registry (part 1 of the adapter call) and returns an adapter instance with myobj as context, ready to be used. That's the instantiation a la str(123) (part 2 of the adapter call) Ah, I think this is becoming clearer... So, as another example, I could register the following as a factory for turning instances of DateTime instances into datetime instances: def convert_dates(date): return datetime(year=date.Year(),month=date.Month(),day=date.Month()) The important thing here, for me, is that the adapted value is not an instance of the adapter factory. Am I getting this now? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Jean-Marc Orliaguet wrote: once you have that utility / adapter you should be able to call it like: converter = getAdapterFor(123, type=IToStringConverter) strResult = converter.convert(123) Not quite, what I'm looking to do is more along the lines of: mystr = getAdapter(123,str) (where str is the interface I'm looking for here) PS: calling '123' an adapter is really bending concepts. Yes, this is a mistake, I believe this should always be referred to as the adapted value or the suggestion Dieter made... cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Chris Withers wrote: Philipp von Weitershausen wrote: Not sure what official terminology glossary you're basing this on, but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. Whatever is called to instantiate that object we call the adapter factory or adapter implementation. The whole zope.component API (both registration and lookup) reflects this use of the terminology. Right, I see where you're coming from now, and I have to agree with Dieter. IZopeDublinCore(myobj) is not an adapter. It is an instance of the adapter or the adapted object, depending on your point of view. We treat adapter and instance of adapter synonymously because the actual implementation of the adapter isn't of interest for us. We explicitly don't care about the implementation by saying IZopeDublinCore(obj). All we want is to get an object that provides IZopeDublinCore. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 21:11 +0100: ... Not sure what official terminology glossary you're basing this on I am basing this on the meaning of english words. An adapter is something that adapts (and not something that is adapted). adapt is a transitive verb. It applies to something. This means that an adapter, too, applies to something. It is a function. but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. I begin to understand where this comes from: In Chris' example, the adaption result is a string. It is very difficult to envision a string as an active object (what the name adapter suggests). In more complex situations the adaptation result is an active object that actively mediates between the interface it provides and the adapted object. This probably led to the use of the active term adapter rather than the more neutral term adaptation (maybe adaption). As Chris example demonstrates, it would have been better to call IZopeDublinCore(myobj) the IZopeDublinCore adaptation of myobj. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Jean-Marc Orliaguet wrote at 2006-11-15 20:51 +0100: ... but what problem is all this supposed to solve? are you guys writing a PhD or something .-) ? Well chosen terminology is a key to understanding. Therefore, it is justified to discuss about it. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Philipp von Weitershausen wrote: IZopeDublinCore(obj) is a flexible version of ZDCAnnotatableAdapter(obj) Flexible, because a different implementation that ZDCAnnotatableAdapter might be used. That's dispatched through the adapter registry. Right, exactly. IZopeDublinCore(myobj) does an adapter lookup based on the type of 'myobj' That's the lookup in the registry (part 1 of the adapter call) and returns an adapter instance with myobj as context, ready to be used. That's the instantiation a la str(123) (part 2 of the adapter call) Ah, I think this is becoming clearer... So, as another example, I could register the following as a factory for turning instances of DateTime instances into datetime instances: def convert_dates(date): return datetime(year=date.Year(),month=date.Month(),day=date.Month()) The important thing here, for me, is that the adapted value is not an instance of the adapter factory. Factories return objects -- that's what they are for. If you register a class as an adapter factory (which the vast bulk of Zope3 applications do) then the adapter returned by the factory will be an instance of that class, because calling the class gives you an instance. Note that in the terms used in Zope3, the *returned object* is the adapter: the callable is the thing which *makes* adapters. Any callable which takes the appropriate number of arguments can be registered as a factory: the only contract is that the return value from the callable is supposed to implement the interface for which the factory was registered. The only (current) exception is subscription adapters, which are registered for 'None' rather than an interface: their return value is *ignored*, because they do all their work when called. We were discussion a (notional) value adapter, whose factory would have the contract of returning an object of a specific concrete type, rather than on implementing an interface. There are reasonable usecases for such adapters, but the CA machinery doesn't permit registering them: it requires that the 'provided' argument be either an interface or None (although the 'required' args can be concrete types). Hope that clarifies, rather than confuses, the discussion. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXR3u+gerLs4ltQ4RAqjQAJ9FcZvkmqC3/xNQ6KOWKHZhRPJD9QCeIR52 SDaTro7khfMJLSM5w2BtsG4= =iGfr -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote:
...hence the quotes. It's a function in that I want to use it as an
adapter that doesn't need to be instantiated by a factory before being
used.
All adapters need to be instantiated.
Why?
def myStrAdapter(something):
return str(something)
This function adapts strings to integers, why would it need to be
instantiated?
No. You always register a factory which is called upon lookup. That's
because adapters are context-dependent and thus need to be instantiated
every time you look them up.
What if they're not context-dependent as in my example above?
ultimately, I'm looking to replace code like the following:
convertors = {
int:{str:str,datetime:datetime},
str:(int:int,datetime:datetime},
}
def convert(x,y):
return convertors[type(x)][type(y)](x)
...if you see what I mean. Apologies for the trivial examples, but these
are real problems...
cheers,
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Chris Withers wrote:
Philipp von Weitershausen wrote:
...hence the quotes. It's a function in that I want to use it as an
adapter that doesn't need to be instantiated by a factory before being
used.
All adapters need to be instantiated.
Why?
def myStrAdapter(something):
return str(something)
This function adapts strings to integers, why would it need to be
instantiated?
I'm not sure this helps (I'm not quite sure what you're trying to do, it
seems a bit crazy), but the realisation that functions could be adapter
factories hit me at some point.
So, when you do an adapter lookup like
foo = IFoo(context)
or
foo = getAdapter(context, IFoo)
or similarly for getMultiAdapter, the CA will:
1. Find the most appropriate adapter registration by looking at the
interfaces on context and finding the most specific adapter to IFoo
2. Call that adapter registration's factory
A factory is just a callable that takes the context (or multiple context's
in the case of a multi-adapter). A class, of course, is a good factory, so
if you have:
class FooAdapter(object):
implements(IFoo)
adapts(IContext)
def __init__(self, context):
self.context = context
and then adapter factory=.foo.FooAdapter /
Then getting an adapter is the same as calling foo.FooAdapter(context) - you
get an object providing IFoo by calling the factory.
You could instead do:
@zope.component.implementer(IFoo)
@zope.component.adapter(IContext)
def fooFactory(context):
newAdapter = FooAdapter(context)
return newAdapter
adapter factory=.foo.fooFactory /
Now, getting the IFoo adapter means calling fooFactory(context). Of course,
it still returns an object providing IFoo, so the contract is still valid.
Incidentally, we use this approach in Plone to fish things out of the ZODB.
You can adapt an object to IPortletAssignments, and we have a factory
function that finds an assignment container (a persistent btree container,
basically) in that object's annotations and returns it. This was a lot less
work than making a dumb transient adapter class that implemented all the
methods of IPortletAssignments (which is a sub-interface of IContainer, so
it has all the dict-like behaviour) and proxied each method call to
annotations on its context. The calling code doesn't care though:
assignments = IPortletAssignments(context)
assignments['my_new_portlet'] = MyNewPortlet()
And of course, if the object wasn't annotatable (say it was a transient
object originating from an SQL database) we could register a different
adapter.
The important point here is that the adapter factory is called each time you
do an adapter lookup. In the most common case, the factory is just a class,
but it could be any callable. If you call a class, you get a new object of
that class, and hence adapter instances tend to be transient, but you could
have a different factory that wasn't.
No. You always register a factory which is called upon lookup. That's
because adapters are context-dependent and thus need to be instantiated
every time you look them up.
What if they're not context-dependent as in my example above?
ultimately, I'm looking to replace code like the following:
convertors = {
int:{str:str,datetime:datetime},
str:(int:int,datetime:datetime},
}
def convert(x,y):
return convertors[type(x)][type(y)](x)
...if you see what I mean. Apologies for the trivial examples, but these
are real problems...
I still think this sounds a little over-complicated, but I'm guessing it's
just because you're de-badging the examples. If convert(x,y) was a
multi-adapter factory, then the above should work.
Martin
--
View this message in context:
http://www.nabble.com/adapter-registration-question-tf2606485.html#a7355564
Sent from the Zope3 - dev mailing list archive at Nabble.com.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Chris Withers wrote:
Philipp von Weitershausen wrote:
...hence the quotes. It's a function in that I want to use it as an
adapter that doesn't need to be instantiated by a factory before
being used.
All adapters need to be instantiated.
Why?
def myStrAdapter(something):
return str(something)
This function adapts strings to integers,
(the other way around)
why would it need to be instantiated?
It instantiates a 'str' object. The 'str' object is the adapter for
'something'. 'myStrAdapter' is the adapter factory.
No. You always register a factory which is called upon lookup. That's
because adapters are context-dependent and thus need to be
instantiated every time you look them up.
What if they're not context-dependent as in my example above?
Then what's the point of an adapter? An adapter factory is supposed to
take at least one argument (context) = the object that it adapts. An
adapter that doesn't adapt anything is, per definitionem, not an adapter.
ultimately, I'm looking to replace code like the following:
convertors = {
int:{str:str,datetime:datetime},
str:(int:int,datetime:datetime},
}
def convert(x,y):
return convertors[type(x)][type(y)](x)
...if you see what I mean. Apologies for the trivial examples, but these
are real problems...
Why not leave it? No need to bend over too hard for solving everything
with the CA :).
--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). 'myStrAdapter' is the adapter factory. In my view, *this* is the adapter (adapting something to str) and not an adapter factory (as its result is a string object which does not adapt anything)... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do That's the terminology abuse: '123' is not an adapter because it does not do the adaption. '123' is the *result* of adapting 123 to 'str'. You may call '123' the 'str' adaption of the integer 123. IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. With appropriate terminology use, you would call IZopeDublinCore the adapter and IZopeDublinCore(myobj) the ZopeDublinCore adaption (maybe adaptation) of myobj. Again IZopeDublinCore(myobj) is not an adapter but an adapted value. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. But I guess Chris wanted to keep the registry lookup part, but not to have to adapt the context. in other words a utility that converts something to a string based on the type to be converted. once you have that utility / adapter you should be able to call it like: converter = getAdapterFor(123, type=IToStringConverter) strResult = converter.convert(123) and reuse it: strResult2 = converter.convert(456) that saves a lot of CPU / memory. PS: calling '123' an adapter is really bending concepts. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do That's the terminology abuse: '123' is not an adapter because it does not do the adaption. '123' is the *result* of adapting 123 to 'str'. You may call '123' the 'str' adaption of the integer 123. IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. With appropriate terminology use, you would call IZopeDublinCore the adapter and IZopeDublinCore(myobj) the ZopeDublinCore adaption (maybe adaptation) of myobj. Again IZopeDublinCore(myobj) is not an adapter but an adapted value. Not sure what official terminology glossary you're basing this on, but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. Whatever is called to instantiate that object we call the adapter factory or adapter implementation. The whole zope.component API (both registration and lookup) reflects this use of the terminology. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100: Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100: ... def myStrAdapter(something): return str(something) It instantiates a 'str' object. The 'str' object is the adapter for 'something'. Huh? This would be a severe terminology abuse: I agree, it's bending the terminology a lot. It wasn't me who came up with the 'str' and 'int' example. An adapter should adapt something to something else *BUT* an str object does not adapt anything (it does not operate on another object). Well, imagine str(123) '123' Here '123' is the 'str' adapter of the integer 123. It's conceptually the same if you do That's the terminology abuse: '123' is not an adapter because it does not do the adaption. '123' is the *result* of adapting 123 to 'str'. You may call '123' the 'str' adaption of the integer 123. IZopeDublinCore(myobj) except that in the str(123) case, you call the class directly instead of using the Component Architecture's registry as a flexible dispatch. With appropriate terminology use, you would call IZopeDublinCore the adapter and IZopeDublinCore(myobj) the ZopeDublinCore adaption (maybe adaptation) of myobj. Again IZopeDublinCore(myobj) is not an adapter but an adapted value. Not sure what official terminology glossary you're basing this on, but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore adapter of myobj. Whatever is called to instantiate that object we call the adapter factory or adapter implementation. The whole zope.component API (both registration and lookup) reflects this use of the terminology. str(123) has the same syntax as IZopeDublinCore(myobj), but semantically there is nothing in common between the two expressions. IZopeDublinCore(myobj) does an adapter lookup based on the type of 'myobj' and returns an adapter instance with myobj as context, ready to be used. but what problem is all this supposed to solve? are you guys writing a PhD or something .-) ? /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Jean-Marc Orliaguet wrote: str(123) has the same syntax as IZopeDublinCore(myobj), but semantically there is nothing in common between the two expressions. I disagree. IZopeDublinCore(obj) is a flexible version of ZDCAnnotatableAdapter(obj) Flexible, because a different implementation that ZDCAnnotatableAdapter might be used. That's dispatched through the adapter registry. IZopeDublinCore(myobj) does an adapter lookup based on the type of 'myobj' That's the lookup in the registry (part 1 of the adapter call) and returns an adapter instance with myobj as context, ready to be used. That's the instantiation a la str(123) (part 2 of the adapter call) but what problem is all this supposed to solve? are you guys writing a PhD or something .-) ? Heh, now that you mention it... ;) -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. ...hence the quotes. It's a function in that I want to use it as an adapter that doesn't need to be instantiated by a factory before being used. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Not really. It's the ability to register the adapter, and change which adapter you choose to use that's important for me here. I think it should be fine to adapt to a class if you can adapt from a class. Is there anything in the implementation that actually prevents this? (which I, for one, would consider a bug) should be: provide=str Wtf? Then why do you need an adapter? See above. I thought you wanted to say IString(1) instead of str(1) to be more flexible...? Hmm, I see your point, but there are other ways to get an adapter than by calling an interface ;-) (and I think I'd need to use those here, since there is no interface) ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). right, but factory= registers and adapter factory, not an adapter and provideAdapter registers an adapter directly, correct? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: Heh, in this case using 'IString' is really a trussed duck (duck typing with BD) ;) Python's duck typing breaks down with strings, because they can by quack tested like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. True, and I guess for my uses, I'd be wanting to register adapter both too and from basestr, since that'd cover unicodes too, unless that would be bad ;) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
whit wrote: hello RuleDispatch... What's RuleDispatch? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Chris Withers wrote: Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. ...hence the quotes. It's a function in that I want to use it as an adapter that doesn't need to be instantiated by a factory before being used. All adapters need to be instantiated. A function can serve as much as an adapter factory as a class. ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). right, but factory= registers and adapter factory, not an adapter and provideAdapter registers an adapter directly, correct? No. You always register a factory which is called upon lookup. That's because adapters are context-dependent and thus need to be instantiated every time you look them up. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: adapter registration question
Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. However, given the edge-case nature of this, I can believe there might be bugs to be found here... Now, you can setup your adapter like this: adapter for=int provides=.interfaces.IString factory=str/ Well, that's not right ;-) should be: provide=str ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... However, given the edge-case nature of this, I can believe there might be bugs to be found here... Now, you can setup your adapter like this: adapter for=int provides=.interfaces.IString factory=str/ Well, that's not right ;-) should be: provide=str Wtf? Then why do you need an adapter? I thought you wanted to say IString(1) instead of str(1) to be more flexible...? ...and factory=str is wrong for the reasons given above, or, put differently, because str()(1) will tell you that strings aren't callable ;-) Huh? You got that wrong. IString(1) will call str(1) if provideAdapter(str, (int,), IString). -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Like adapting to None? Using adaptation to look up value factories is not any weirder than using it to look up event subscribers whose return values are always discarded. Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWK2o+gerLs4ltQ4RAsNxAJ4uXSOSup8PyQd2lQPm1Fqr/C3fGgCgwmiG PgKweYkpKMpulOK46qtJFx0= =twN/ -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: Philipp von Weitershausen wrote: Chris Withers wrote: Christian Theune wrote: The problem you have is to provide a specification for the 'str' interface. There are a couple of problems here... 1. str is both a function and a class Nope. It's a class since Python 2.2. 2. I was to register the function str as an adapter for, say, the class int to the class str, so there's not factory for the adapter, since it's a function Let's create a marker interface that promises everything that 'str' does: class IString(zope.interface.Interface): A marker for the 'str' interface. As discussed elsewhere, you shouldn't need the marker interface, as you can adapt classes. Right, as an *input* of the adaption it's ok just to specify a class. But the output obviously always has to be specified by an interface. Otherwise the whole point of using of adaption is perverted... Like adapting to None? Heh, good point. Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Well, part of Python idea is duck typing and requiring that you get a 'str' may be too much. Perhaps you would really only like to get something that quacks like str. OTOH, perhaps you absolutely want a 'str' and that use case should perhaps be allowed... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: snip Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Well, part of Python idea is duck typing and requiring that you get a 'str' may be too much. Perhaps you would really only like to get something that quacks like str. OTOH, perhaps you absolutely want a 'str' and that use case should perhaps be allowed... Heh, in this case using 'IString' is really a trussed duck (duck typing with BD) ;) Python's duck typing breaks down with strings, because they can by quack tested like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFWLUf+gerLs4ltQ4RAt/1AKCUvR230iCgNOq7kUpqAcFrSQVp5wCfedXY WI/ty3z7ektpMS/9Mh+l/PI= =IM7g -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: snip Thnk of cataloguing / indexing use cases: adapting the catalogued object to a string value (or tuple, or whatever) using named adapters is a very natural way to make indexing pluggable: what is *unnatural* (or at least a dead chicken) is the requirement to adapt to an 'IString', when what I really want is a 'str'. Well, part of Python idea is duck typing and requiring that you get a 'str' may be too much. Perhaps you would really only like to get something that quacks like str. OTOH, perhaps you absolutely want a 'str' and that use case should perhaps be allowed... Heh, in this case using 'IString' is really a trussed duck (duck typing with BD) ;) Python's duck typing breaks down with strings, because they can by quack tested like sequences, but you almost *never* want to treat them the same way as other sequences, so you end up with 'isinstance(obj, basestr)' tests to prevent handling them that way. hello RuleDispatch... -w ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: adapter registration question
On Fri, 2006-10-11 at 08:00 +, Chris Withers wrote: This is a toy example, but I need to do something similar and can't seem to get the registration right... How can I register the str builtin as an adapter from python int objects to python str objects? I've personally found when I run into a situation where it seems like I need to adapt on the builtin str class, I should probably be using named adapters or named utilities instead. I use this technique for example to lookup mime type stuff in one of my apps. adapter for=* name=text/html factory=.somemodule.SomeClass provides=.interfaces.ISomeMimeTypeHandlerThingie / from zope import component component.getAdapter(randomobj, ISomeMimeTypeHandlerThingie, name='text/html') - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
