[Python-3000] Abilities / Interfaces

Ron Adam rrr at ronadam.com
Wed Nov 22 01:02:28 CET 2006


Guido van Rossum wrote:
> I thought I addressed that (search my mail for "Antoine Pitrou"); I
> expect that this will be too slow for use by the dispatch mechanism
> for generic functions (or adapt, or anything else that makes use of
> interfaces assuming the declared and actual interface match).

I wasn't able to find the referenced message in this news group or on gmane, 
but Andrew Koenig's recent post in this thread is along the lines of what I was 
thinking.


> On 11/21/06, Ron Adam <rrr at ronadam.com> wrote:
>> Guido van Rossum wrote:
>>> On 11/20/06, Guido van Rossum <guido at python.org> wrote:
>>>> I'd like to have a discussion of abilities and interfaces but right
>>>> now I don't have time -- maybe tomorrow. I see Andrew's proposal as
>>>> mostly isomorphic to Zope's notion of interfaces, but the new
>>>> terminology may make it possible to clarify certain distinctions
>>>> better, e.g. the distinction between a class that provides an ability
>>>> to its instances, and the abilities that an instance has.
>>>>
>>>> Feel free to riff on this theme here. I'll check in within 24 hours or so.
>>> OK, I have some more time for this now. I'm hoping Andrew, Bill and
>>> Phillip will join the discussion here (instead of various other
>>> threads).
>>
>>> I'd like to explore this some more before committing to anything.
>>
>> Here's a thought:
>>
>> For identifying abilities, it almost seems like instead of hard coding a library
>> of this is that relationships, which will always be incomplete and possibly easy
>> to fool, an ability might be described as a small (minimal) test that a
>> interface can pass.


>> Registering an ability relationship could require running
>> it against an ability test prior to use.

To be a bit clearer, I meant here, that running an ability test-unit could be 
part of the pre-registration (or other setup) process and needn't be done at a 
function's or method's call time.


>> It doesn't have to be done just prior to use.  It could be done at import time,
>> or even earlier with the result restored at application run time so it can be a
>> one time cost for most applications.
>>
>> This may make it more open ended and add a level of actual testing that may be
>> useful for debugging as well.
>>
>> Ron





More information about the Python-3000 mailing list