[Python-3000] Abilities / Interfaces

[Ron Adam]

Greg Ewing wrote:
> Gustavo Niemeyer wrote:
>> Are you arguing that
>> pretty much every approach being discussed is bad and
>> we should instead implement something magically
>> transforming types?
> 
> No, I'm questioning the need to do anything at all.
> I don't see a big problem that merits a heavyweight
> solution like a formal interface or adaptation
> framework.
> 
> --
> Greg

I think I agree with you Greg,  although it is still early and something simpler 
and possibly more direct may yet come from the discussion.  It does look like it 
is starting to be a bit more focused.

It might be nice to have some selected examples of current library code that may 
benefit from interfaces/abilities, with a brief comment of where it currently 
falls short for each example.  These may be useful later in a PEP.


Earlier messages here had sometimes vague suggestions of what interfaces would 
do, but it seems different people have different ideas of that.  Some of those 
implied ideas are:

[A probably incomplete list with letter for referencing]

     (A.) Better introspection to use in situations where type(), isinstance(), 
or hasattribute(), is perceived as being less than optimal.

     (B.) Adding an additional or alternate method of auto-dispatching either 
through generic functions or though the class structure.

     (C.) Selecting an Adapter, or using adapters.

     (D.) Verifying or Testing a function/object/or method to determine it's 
ability or signature. (Or some other variation of pragmatically determining a 
signature.)

I believe Guido already set aside discussion of "C" and "D", as they are 
implementation details that can be examined separately and added later if it 
they seem to be promising. (Guido may have other reasons.)

So that leaves "A" and "B". Most of the discussion is focused on "B" at the 
moment. The optional signatures proposed in a different thread may serve for 
"A".  I don't know how much "A" and "B" overlap, possibly only a little or not 
at all depending on how "B" is implemented, or it may be that a good solution to 
"A" is needed in order for "B" to work well enough to bother with.


It may also be that only a good unified solution to "A" is needed in order to 
allow library and user code to be written "easier" to address "B","C" and "D". 
It may even be just doing "A" is a good enough 95% solution (works well enough 
for 95% of actual use cases) and nothing more needs to be done. <It's too soon 
to tell>

There has also been put forth various, (also sometimes vague), suggestion of 
just what item "A" is.  Does "A" return information of "is_a", "has_a", or 
"does_a" relationships?  A "does_a" relationship may be difficult to define. 
Mixing these in a signature may not be as straight forward as it may seem.  The 
optional signatures addresses "is_a" relationships fairly well, but not "has_a" 
or "does_a" relationships.

Anyway, I'm waiting on a PEP and hoping I will be able to understand it.  A 
difficult to understand and use 99% solution is probably not better than what we 
currently have I think.

Cheers,
    Ron