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 ac
-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
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 raise
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 (n
-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 n
-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 wa
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 no
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
registra
On Thu, Dec 17, 2009 at 15:56, Martijn Faassen 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 apart a bit but I
don
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(co
Lennart Regebro wrote:
> On Thu, Dec 17, 2009 at 02:53, Tres Seaver 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
>> me
On Thu, Dec 17, 2009 at 02:53, Tres Seaver 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 the trunk a 3.6.0
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
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 requir
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?
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 wild which looks like::
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 t
-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.componen
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 rea
-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: obvi
-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/registr
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
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 dumm
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
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 enou
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
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
-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 Typ
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
-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
-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,
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
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
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 th
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 m
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 modelled on the exisiting `__call__`. In particular, the new methods
36 matches
Mail list logo
