Tres Seaver wrote:
I guess it must be, since calling an interface already does some adaptation.
No, there is no dependency: zope.interface defines a hook point that
zope.component uses. In the absence of zope.component, zope.interface
uses a default implementation.
That sound pretty icky.
Brandon Craig Rhodes wrote:
I'm encouraged by the fact that this time it looks like people with time
are interested enough to actually begin producing code? At the time
that I made the 2007 proposal I was still very new to the code base and
never got the courage up (or time available) to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
Brandon Craig Rhodes wrote:
I'm encouraged by the fact that this time it looks like people with time
are interested enough to actually begin producing code? At the time
that I made the 2007 proposal I was still very new to
Chris Withers wrote at 2008-9-22 19:41 +0100:
Shane Hathaway wrote:
+1 from me as well on IFoo.adapt() with the signature Chris suggested.
zope.component.getMultiAdapter() is only easy to remember if you're a
die-hard Zope coder, while IFoo.adapt() seems more useful to the larger
Python
Shane Hathaway [EMAIL PROTECTED] writes:
Philipp von Weitershausen wrote:
So overall I'm +1
+1 from me as well on IFoo.adapt() with the signature Chris suggested.
zope.component.getMultiAdapter() is only easy to remember if you're a
die-hard Zope coder, while IFoo.adapt() seems more
Chris Withers wrote at 2008-9-8 18:34 +0100:
...
There's the backward-compatibility issue, which is a showstopper.
There's plenty of code that does this:
adapter = package.interfaces.IFoo(object, None)
Changing the signature as you describe would break all code that does this.
How
On Tue, Sep 9, 2008 at 2:37 PM, Dieter Maurer [EMAIL PROTECTED] wrote:
The syntax would be a bit more cumbersome -- but on the other
hand, it would be more explicit :-)
Seems to me zope.component.getMultiAdapter(...) is sufficient as-is,
and shares the benefit of explicitness.
That's
El 9 Sep 2008, a las 20:37 , Dieter Maurer escribió:
Chris Withers wrote at 2008-9-8 18:34 +0100:
...
There's the backward-compatibility issue, which is a showstopper.
There's plenty of code that does this:
adapter = package.interfaces.IFoo(object, None)
Changing the signature as you
Philipp von Weitershausen wrote:
El 9 Sep 2008, a las 20:37 , Dieter Maurer escribió:
But interfaces might grow an additional method, e.g. adapt,
which could get the new signature.
The syntax would be a bit more cumbersome -- but on the other
hand, it would be more explicit :-)
I don't
On Sun, Sep 7, 2008 at 3:29 PM, Chris Withers [EMAIL PROTECTED] wrote:
I can't see any problems with this, can anyone else?
There's the backward-compatibility issue, which is a showstopper.
There's plenty of code that does this:
adapter = package.interfaces.IFoo(object, None)
Changing the
Fred Drake wrote:
On Sun, Sep 7, 2008 at 3:29 PM, Chris Withers [EMAIL PROTECTED] wrote:
I can't see any problems with this, can anyone else?
There's the backward-compatibility issue, which is a showstopper.
There's plenty of code that does this:
adapter =
On Sep 1, 2008, at 12:33 PM, Philipp von Weitershausen wrote:
El 1 Sep 2008, a las 17:23 , Chris Withers escribió:
Philipp von Weitershausen wrote:
I've personally thought for some time that it would be quite nice
if all you had to do was call an interface to look up a utility
(which is
Jim Fulton wrote:
Some people who use zope.interface reply on being able to singly adapt
tuples
I've heard this before, but I've always been curious: why? when is this
a pattern you'd want to use?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to
El 30 Aug 2008, a las 07:50 , Dieter Maurer escribió:
Chris Withers wrote at 2008-8-29 10:25 +0100:
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional
parameters --
what a simplification and
Philipp von Weitershausen wrote:
I've personally thought for some time that it would be quite nice if
all you had to do was call an interface to look up a utility (which is
sort of a multi-adapter of order 0) or to do some kind of adaption, no
matter how many objects you wanted to adapt.
El 1 Sep 2008, a las 17:23 , Chris Withers escribió:
Philipp von Weitershausen wrote:
I've personally thought for some time that it would be quite nice
if all you had to do was call an interface to look up a utility
(which is sort of a multi-adapter of order 0) or to do some kind
of
Philipp von Weitershausen wrote at 2008-9-1 14:07 +0200:
...
I've personally thought for some time that it would be quite nice if
all you had to do was call an interface to look up a utility (which is
sort of a multi-adapter of order 0) or to do some kind of adaption, no
matter how many
Chris Withers wrote at 2008-9-1 16:23 +0100:
...
auth = IAuthentication() # utility
auth = IAuthentication(default=None)
langs = IUserPreferredLanguages(request) # adapter
langs = IUserPreferredLanguages(request, default=None)
El 1 Sep 2008, a las 19:26 , Dieter Maurer escribió:
Chris Withers wrote at 2008-9-1 16:23 +0100:
...
auth = IAuthentication() # utility
auth = IAuthentication(default=None)
langs = IUserPreferredLanguages(request) # adapter
langs =
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or homogenisation been a goal of
Zope 3? ;-)
Chris
Dieter Maurer wrote:
Jim is heavily defending this difference.
I am convinced that the difference should not be there
fork anyone? ;-)
but meanwhile have found a use case for it.
Suppose, you have a class C that implements I.
If queryAdapter would behave like I(...), you
would
Chris Withers wrote at 2008-8-29 10:25 +0100:
Dieter Maurer wrote:
Then, we could get rid of the {get|query}[Multi]Adapter altogether
and consistently use I() with appropriate optional parameters --
what a simplification and homogenization :-)
Yeah, but since when has simplification or
Chris Withers wrote at 2008-8-19 18:30 +0100:
...
class ISomething(Interface): pass
...
class MyClass: implements(ISomething)
...
m = MyClass()
Right, so this does make sense:
ISomething(m)
__main__.MyClass instance at 0x00BED6E8
This does not:
repr(queryAdapter(m,ISomething))
'None'
Jim Fulton wrote at 2008-8-19 17:57 -0400:
While I respect that this feature may have been chosen carefully, it
nevertheless seems more like a misfeature. Chris' expectation was
reasonable and ought not to be violated without a good cause.
queryAdapter is used to look up named adapters.
Shane Hathaway wrote:
It sure would be nice if it had a docstring that at least indicated that
was its only intended purpose.
Now would be a good time for you to add that docstring to the trunk. :-)
Yes well, I apparently don't have enough knowledge to do this correctly.
Maybe someone with
Marius Gedminas wrote:
On Tue, Aug 19, 2008 at 11:19:12PM +0100, Chris Withers wrote:
However, how should I go about adapting an object to an interface where
there may or may not be an adapter registered?
obj = ISomething(otherobj, None)
Ah, okay. Now I remember. I've often wanted to be
On Tue, Aug 19, 2008 at 11:19:12PM +0100, Chris Withers wrote:
However, how should I go about adapting an object to an interface where
there may or may not be an adapter registered?
obj = ISomething(otherobj, None)
The natural way would seem to be:
obj = ISomething(otherobj,default=None)
From a user's perspective, this makes no sense:
from zope.interface import implements,Interface
from zope.component import queryAdapter
class ISomething(Interface): pass
...
class MyClass: implements(ISomething)
...
m = MyClass()
Right, so this does make sense:
ISomething(m)
Shane Hathaway wrote:
Chris Withers wrote:
From a user's perspective, this makes no sense:
from zope.interface import implements,Interface
from zope.component import queryAdapter
class ISomething(Interface): pass
...
class MyClass: implements(ISomething)
...
m = MyClass()
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
Looks like a bug to me. If the object passed as the first argument to
queryAdapter() implements the interface passed as the second argument, I
believe queryAdapter() should return the object, regardless of any
component registrations.
Shane Hathaway wrote:
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
Looks like a bug to me. If the object passed as the first argument to
queryAdapter() implements the interface passed as the second argument, I
believe queryAdapter() should return the object, regardless of any
On Aug 19, 2008, at 4:24 PM, Shane Hathaway wrote:
Philipp von Weitershausen wrote:
Shane Hathaway wrote:
Looks like a bug to me. If the object passed as the first
argument to
queryAdapter() implements the interface passed as the second
argument, I
believe queryAdapter() should
Philipp von Weitershausen wrote:
No, it's not a bug. This is in fact a feature (like it or not).
Well, assuming enough people *don't* like it, and I think that's the
case here, then it should probably change...
{query|get}Adapter will always try to look up an adapter, whether or not
the
Jim Fulton wrote:
No, it's not a bug. This is in fact a feature (like it or not).
While I respect that this feature may have been chosen carefully, it
nevertheless seems more like a misfeature. Chris' expectation was
reasonable and ought not to be violated without a good cause.
Chris Withers wrote:
Jim Fulton wrote:
No, it's not a bug. This is in fact a feature (like it or not).
While I respect that this feature may have been chosen carefully, it
nevertheless seems more like a misfeature. Chris' expectation was
reasonable and ought not to be violated without a good
35 matches
Mail list logo
