[Python-3000] iostack and Oh Oh

[Samuele Pedroni]

Guido van Rossum wrote:
> On 12/1/06, Paul Moore <p.f.moore at gmail.com> wrote:
>   
>> On 11/30/06, Bill Janssen <janssen at parc.com> wrote:
>>     
>>>> so no offense in advance.
>>>>         
>>> Sure, no offense taken.  I've seen comments like this before on this
>>> list (recently :-).  I think both approaches (interface types and duck
>>> typing) are complicated in different ways.
>>>       
>> Instinctively, I agree with Tomer on this issue. But I'm reasonably
>> relaxed about the matter as long as it's optional. What I'm not sure
>> about, is if that is the intention. For example,
>>
>>     class MyMap:
>>         def __getitem__(self, key): ...
>>         def __setitem__(self, key, value): ...
>>
>> If I pass this into a function (written by a 3rd party, so I have no
>> way of changing it) that *only* uses the syntax m[k] on it (never
>> needs to do len(m), or m.keys() or anything else), will it work?
>> Please note that MyMap is deliberately written to *not* conform to any
>> of your proposed base classes.
>>     
>
> It would still work, *unless* the code that receives this object does
> an explicit check for whether its argument implements some Mapping
> interface or ABC.
>
>   
>> If it doesn't work, then my code is excluded from using a perfectly
>> good piece of 3rd party code for no reason. Sure, I can "fix" the
>> problem by implementing a few extra methods (just raising an exception
>> if they are called) and possibly declaring that I conform to an
>> interface (which, actually, I don't). But why should I have to?
>>     
>
> If the 3rd party code makes it part of its API requirements that you
> must only pass it an object that implements a certain interface, then
> you had better conform to that requirement. 
but the hierarchy is too imprecise to avoid the 3rd party making too 
narrow requirements.
 From that point of view the ability to refer easily to subsets of  
interfaces is seems quite crucial
to reflect current Python usage.

Also the built-in types are concrete types, which tend to maximize  
convenience. It's unclear
that they are a good starting point to define interfaces, because of 
this maximality.
Especially if there's no standard way to do adaptation instead of just 
checking for
the interface, or have derivable methods implemented automatically from 
a minimal subset.

I suppose there's a reason that interfaces and adaptation go together in 
their current usages
in Python.

In some sense that from the fact that we would like to distinguish 
stringish stuff and
mappings (in a minimal sense) from sequences, we generalize to wanting 
interfaces
for the core of Python, is quite a jump, especially if then we don't 
want all the baggage
of how interfaces are practiced today by large frameworks, because this 
is essentially
an unproven solution. Comparisons with Java don't really help, the 
latter is still
a statically typed language.

> The 3rd party code may
> have a plan for evolving the implementation in such a way that
> eventually it *will* require all the functionality of that interface,
> and they would prefer that you are warned of this possibility in
> advance.
>
>   
>> I appreciate that this is an oversimplified argument, and that
>> interfaces/ABCs/GFs/whatever have significant value within certain
>> types of framework - but you're not proposing a hierarchy for
>> framework-specific classes here, but rather for the fundamental types
>> of the language.
>>     
>
> The proposal provides a better way to check whether something
> implements a particular interface. It doesn't propose adding any
> automatic type checking to the language.
>   



> If you were writing a framework today, and you had to design an API
> that took either a sequence or a mapping -- how would you distinguish
> the two? Both implement __getitem__, __iter__ and __len__. Would you
> test for the presence of a keys() method, even if you have no need to
> ever call it? What makes keys() special? With interfaces or ABCs, you
> can test whether it implements the Mapping or Sequence API (or some
> more primitive base for those).
>
>   
>> If the proposed class hierarchy is going to have an impact on code
>> which is not written around a framework (like Twisted) which is built
>> on interfaces, the result won't feel like Python to me, as far as I
>> can see...
>>     
>
> Of course. And nobody is proposing that.
>
>