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
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
>>
-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
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 s
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() se
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 community.
So if we're all in agreement, wh
Philipp von Weitershausen wrote:
> So overall I'm +1
Me too!
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo
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 :-)
>
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
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 suffic
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 t
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 = package.interfaces.
Chris Withers wrote:
> Philipp von Weitershausen wrote:
>>> Right, but how do you differentiate adapting a tuple to IBrowserPage
>>> versus adapting obj and request together to IBrowserPage?
>> You don't, I guess. I'd say that multi-adaption is *defined* as the
>> adaption of a tuple.
>
> Well
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 th
Philipp von Weitershausen wrote:
>> Right, but how do you differentiate adapting a tuple to IBrowserPage
>> versus adapting obj and request together to IBrowserPage?
>
> You don't, I guess. I'd say that multi-adaption is *defined* as the
> adaption of a tuple.
Well no, I think Dieter suggeste
On Tuesday 02 September 2008, Martin Aspeli 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?
Ask the twisted guys. :-)
Regards,
Stephan
--
Step
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 wo
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
>>> (
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
>>>
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
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
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
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 ada
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 simplifi
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 simplific
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(...)"
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? ;-)
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 a
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(quer
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
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
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=No
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 w
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.
>
> q
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
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 queryAdapt
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
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 regist
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)
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()
>
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:
>>> ISo
41 matches
Mail list logo
