Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-19 Thread Martijn Faassen
Tres Seaver wrote: [snip] If __call__ is an API, why is it not documented where the rest of the API for Interface is specified? I think you shouldn't focus on documentation to the exclusion of the practical situation, which is that people have been calling interfaces for many years now to

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-18 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-18 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Lotze wrote: Martijn Faassen wrote: Hey, Tres Seaver wrote: [snip] Any code today which wants a utility is calling 'getUtilty' (if it *knows* the utility must be registered) or 'queryUtility' (if it thinks it might not be). Less

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-18 Thread Martijn Faassen
Hey, Tres Seaver wrote: [let's not suddenly change the behavior of __call__ for backwards compatibility reasons] If so, that code is already broken: it depends on an undocumented implementation detail (of a non-API method). The patch makes the __call__ method an API, and documents the

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-18 Thread Martijn Faassen
Martijn Faassen wrote: [snip] If you do insist on taking that position, then please note that while API may not be documented in zope.interface... actually the API is documented in zope.interface's README.txt, including TypeError: If an object cannot be adapted, then a TypeError is

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-18 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Tres Seaver wrote: [let's not suddenly change the behavior of __call__ for backwards compatibility reasons] If so, that code is already broken: it depends on an undocumented implementation detail (of a non-API

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Martijn Faassen
Thomas Lotze wrote: [snip] - The very concept of the ZCA introduces a related problem with code readability: just by reading the code that uses components you will never be able to tell where a particular adapter or utility comes from, or even what adapters or utilities you can hope to

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Martijn Faassen
Hey, Tres Seaver wrote: [snip] - -1 to any docstring / exception method which points outside the zope.itnerface package. There is a perfectly reasonable default implementation anyway (in the absence of any hooks): You're against a docstring talking about zope.component overriding these?

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Martijn Faassen
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide zope.component's API functions and then turn around and require folks to import

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Thomas Lotze
Martijn Faassen wrote: Hey, Tres Seaver wrote: [snip] Any code today which wants a utility is calling 'getUtilty' (if it *knows* the utility must be registered) or 'queryUtility' (if it thinks it might not be). Less facetiously than my first challenge: please point to actual code in the

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Lennart Regebro
On Thu, Dec 17, 2009 at 02:53, Tres Seaver tsea...@palladion.com wrote: I have checked in a branch which makes failed adaptation (inside the __call__ of an interface) raise a LookupError instead of a TypeError: the branch also documents the semantics of __call__.  I would like to merge this to

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Martijn Faassen
Lennart Regebro wrote: On Thu, Dec 17, 2009 at 02:53, Tres Seaver tsea...@palladion.com wrote: I have checked in a branch which makes failed adaptation (inside the __call__ of an interface) raise a LookupError instead of a TypeError: the branch also documents the semantics of __call__. I

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Marius Gedminas
On Wed, Dec 16, 2009 at 04:48:06PM -0500, Tres Seaver wrote: There is a perfectly reasonable default implementation anyway (in the absence of any hooks): - IFoo.adapt(context) raises LookupError, unless the context provides IFoo, in which case it returns context. - IFoo.adapt(context,

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Lennart Regebro
On Thu, Dec 17, 2009 at 15:56, Martijn Faassen faas...@startifact.com wrote: Is there a backwards compatibility import? Nope. We could put one there, but I thought we might want to deprecate it in zope.testing instead. We can do both of course. zope.testing.doctest and stdlibs doctest has grown

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Martijn Faassen
Marius Gedminas wrote: [snip] So I'm -99 for magical side effects of import statements, but thankfully the community opinion is already against them. Yeah, I was a bit too cavalier in earlier discussions about such a solution. Tres suggested having a proper plugin API for this and a

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-17 Thread Brian Sutherland
On Tue, Dec 15, 2009 at 05:32:15PM -0500, Chris McDonough wrote: I wonder if maybe something like (notionally): class InterfaceBase(object): @classmethod def add_more_api(cls, **kw): cls.__dict__.update(kw) I like this as a clear point to put a pdb when things do not go

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Martijn Faassen
Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods would bear that name, and

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Thomas Lotze
Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that of utilities as one of the dummy methods

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Thomas Lotze
Thomas Lotze wrote: I'm not sure whether we should make the name of that parameter consistent between zope.component and zope.interface, Sorry, nevermind. Of course we'll want to rename that parameter as our secret plan is to access the ZCA through Interface.__call__ one day. -- Thomas

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: Martin Aspeli wrote: zope.component raises TypeError if you can't adapt. It raises ComponentLookupError it can't find a utility. Not so: see $ZSVN/zope.component/trunk/src/zope/component/registry.py:

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Thomas Lotze wrote: Martijn Faassen wrote: * have dummy implementations in zope.interface that raise NotImplementedError That would still introduce too many zope.component concepts into zope.interface IMO: obviously that

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Martin Aspeli
Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide zope.component's API functions and then turn around and require folks to import zope.component just to catch its local exception types. Yeah, that's a compelling reason.

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-16 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: In either case, I think TypeError (or maybe LookupError) is the *right* choice: we don't want to hide zope.component's API functions and then turn around and require folks to import zope.component just to

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Matthias Lehmann
Am Dienstag 15 Dezember 2009 17:16:12 schrieb Thomas Lotze: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Leonardo Rochael Almeida
Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Martijn Faassen
Hey, Good to see there's progress! Thomas Lotze wrote: [snip] Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Chris McDonough
I wonder if maybe something like (notionally): class InterfaceBase(object): @classmethod def add_more_api(cls, **kw): cls.__dict__.update(kw) - C Leonardo Rochael Almeida wrote: Funny you should mention this, I've got this idea bugging for a few weeks now, after the last

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leonardo Rochael Almeida wrote: Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name,

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Good to see there's progress! Thomas Lotze wrote: [snip] Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Martin Aspeli
Tres Seaver wrote: * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a ComponentLookupError? I was thinking we should keep the behavior as

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Martin Aspeli
Tres Seaver wrote: +1 to TypeError: nobody really cares about the type of the error: code that wants to be robust about a failure uses the 'query' methods. As long as the message is informative enough (which ComponentLookupError isn't, really) we should be fine. If we made CLE derive from

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Thomas Lotze
Martijn Faassen wrote: * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. A TypeError instead of a ComponentLookupError? I was thinking we should keep the behavior

Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Christian Theune
On 12/15/2009 11:32 PM, Tres Seaver wrote: Given that the choice to use __call__ is not widely enough accepted, I think something like your solution makes sense. I'm not sure that hooking __getattr__ is going to be performant enough, but a similar mechanism probably could be made fast enough.