Hey,
Chris McDonough wrote:
[snip experiment folding zope.component bits into zope.interface]
> I thought maybe it might be a bit easier (I thought maybe I could get it done
> today) so I'm going to give up the idea of doing it "on spec" without some
> positive feedback about the idea.
Thanks f
Chris McDonough wrote:
> Thomas Lotze wrote:
>> Chris McDonough wrote:
>>
>>> Thomas Lotze wrote:
Because then, if you use third-party code that uses
zope.interface.Interface and other code (third-party or your own) that
uses the subclassed interfaces, you'll have to deal with both t
Thomas Lotze wrote:
> Chris McDonough wrote:
>
>> Thomas Lotze wrote:
>>> Because then, if you use third-party code that uses
>>> zope.interface.Interface and other code (third-party or your own) that
>>> uses the subclassed interfaces, you'll have to deal with both types at
>>> the same time in y
Hey,
A few points instead of a point by point reply.
* I thought we had agreed to add methods to Interface that support multi
adapter and utility lookup. We seem to have, but only about the external
API, not about where the implementation is. (even if in my plugin
proposal the implementation s
Chris McDonough wrote:
> Thomas Lotze wrote:
>> Because then, if you use third-party code that uses
>> zope.interface.Interface and other code (third-party or your own) that
>> uses the subclassed interfaces, you'll have to deal with both types at
>> the same time in your client code. You could us
Thomas Lotze wrote:
> Chris McDonough wrote:
>
>> I'll throw out the obvious...
>>
>> Why not subclass Interface in zope.component and make the required API
>> additions there? If it were anybody but us thinking about doing this,
>> they'd probably just subclass.
>
> Because then, if you use thi
Hi,
this is a long message with a lot of replies to things that I don't agree
with. Since I realize that making those points over and over again doesn't
get us anywhere, I'd like to point out first that I'm going to implement
Martijn's suggestions anyway on one of my branches, hoping that seeing
m
Chris McDonough wrote:
> I'll throw out the obvious...
>
> Why not subclass Interface in zope.component and make the required API
> additions there? If it were anybody but us thinking about doing this,
> they'd probably just subclass.
Because then, if you use third-party code that uses
zope.int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ethan Jucovy wrote:
> Hi,
>
> On Fri, Dec 18, 2009 at 9:47 AM, Lennart Regebro wrote:
>> On Fri, Dec 18, 2009 at 08:51, Brian Sutherland
>> wrote:
>>> I like things to fail noisily and loudly unconfigured and give good
>>> information about what's
Ethan Jucovy wrote:
> +1 from my perspective of "I don't know or understand the core ZCA
> codebase very well (and don't understand all the implications in this
> discussion) but often read or trace through the code." A
> well-documented NotImplementedError seems much more human-useful than
> a de
Hi,
On Fri, Dec 18, 2009 at 9:47 AM, Lennart Regebro wrote:
> On Fri, Dec 18, 2009 at 08:51, Brian Sutherland
> wrote:
>> I like things to fail noisily and loudly unconfigured and give good
>> information about what's wrong.
>
> +1
[snip]
> we make zope.interface aware that such a thing as util
On Fri, Dec 18, 2009 at 08:51, Brian Sutherland wrote:
> I like things to fail noisily and loudly unconfigured and give good
> information about what's wrong.
+1
> So my preferred implementation of a
> stub "utility" function on Interface is:
>
> def utility(default=None):
> """Lookup
Wolfgang Schnerring wrote:
> * Martijn Faassen [2009-12-17 17:48]:
>> * Thomas Lotze :
>>> zope.interface [should be] completely unaware of any particular uses
>>> of interfaces
>> Why is it a problem that the zope.interface package gains knowledge
>> about adaptation (which it always had, anyway
* Martijn Faassen [2009-12-17 17:48]:
> * Thomas Lotze :
> > zope.interface [should be] completely unaware of any particular uses
> > of interfaces
>
> Why is it a problem that the zope.interface package gains knowledge
> about adaptation (which it always had, anyway) and utility lookup?
This i
On Thu, Dec 17, 2009 at 04:59:12PM +0100, Thomas Lotze wrote:
> Martijn Faassen wrote:
> > Their behavior should be:
> >
> > IFoo.adapt(context) raises LookupError, unless the context provides IFoo,
> > in which case it returns context.
> >
> > IFoo.adapt(context, default=default) returns default
Hey,
Marius Gedminas wrote:
> I'd like to advance the following argument that I haven't seen yet in
> this thread: discoverability.
I was actually thinking very much about people who read the code all the
time, but apparently I wasn't very clear. That's also why I moved away
from a position
On Thu, Dec 17, 2009 at 05:48:04PM +0100, Martijn Faassen wrote:
> Thomas Lotze wrote:
> > I think looking at that API explains why we have trouble with having stub
> > methods defined by zope.interface: these methods contain enough
> > information about component concepts to blur the distinction b
Chris McDonough wrote:
> Martijn Faassen wrote:
>> Chris McDonough wrote:
>>> I'll throw out the obvious...
>>>
>>> Why not subclass Interface in zope.component and make the required API
>>> additions there? If it were anybody but us thinking about doing this,
>>> they'd
>>> probably just subcl
Martijn Faassen wrote:
> Chris McDonough wrote:
>> I'll throw out the obvious...
>>
>> Why not subclass Interface in zope.component and make the required API
>> additions there? If it were anybody but us thinking about doing this,
>> they'd
>> probably just subclass.
>
> Because then we'd need
Chris McDonough wrote:
> I'll throw out the obvious...
>
> Why not subclass Interface in zope.component and make the required API
> additions there? If it were anybody but us thinking about doing this, they'd
> probably just subclass.
Because then we'd need to rebase all our interfaces to be a
We've been through this option recently already. It has been quickly
shot down by those who want interfaces to get the new behaviour
immediately available in existing interfaces, instead of having to
rewrite already existing interfaces to support the new API.
Painful memories of a time when we had
Yeah, I was thinking that too, as a "I don't have time to think hard about
this" little daydream.
Actually I believe you would want to subclass InterfaceClass and make your new
zope.component.Interface an instance of the new InterfaceClass and specify
zope.interface's Interface as something i
I'll throw out the obvious...
Why not subclass Interface in zope.component and make the required API
additions there? If it were anybody but us thinking about doing this, they'd
probably just subclass.
- C
Martijn Faassen wrote:
> Wichert Akkerman wrote:
> [knip]
>> Perhapse LookupError shoul
Hey,
Thomas Lotze wrote:
[snip]
>> * We want to implement .adapter(), .utility() and .__call__() in
>> zope.component as much as possible.
>
> The method's name is `adapt`, JFTR.
Whoops, yes, I prefer 'adapt' actually anyway. :)
>> * we want a similar mechanism for each of them to plug in.
>
>
Wichert Akkerman wrote:
[knip]
> Perhapse LookupError should be a subclass of TypeError.
It's a Python built-in. :)
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML
Martijn Faassen wrote:
> Here's a summary of what has been going on in this thread with some
> attempts at conclusions that have support of the consensus so that Thomas
> can proceed
Thank you, half an hour later and I'd have written the summary ;o)
> * We want to implement .adapter(), .utility(
Hey,
Ethan Jucovy wrote:
> On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
> wrote:
>> * It'd be nice if __call__ came back with a LookupError instead of
>> a TypeError, but how to get from A to B without breakage?
>
> Maybe I've misunderstanding, but what's the advantage of making
> IFoo(x)
On 12/17/09 16:36 , Ethan Jucovy wrote:
> Hi,
>
> On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
> wrote:
>> * It'd be nice if __call__ came back with a LookupError instead of a
>> TypeError, but how to get from A to B without breakage?
>
> Maybe I've misunderstanding, but what's the advantage
Hi,
On Thu, Dec 17, 2009 at 10:15 AM, Martijn Faassen
wrote:
> * It'd be nice if __call__ came back with a LookupError instead of a
> TypeError, but how to get from A to B without breakage?
Maybe I've misunderstanding, but what's the advantage of making
IFoo(x) raise a LookupError instead of a T
29 matches
Mail list logo
