[Types-sig] Interface PEP

[Samuele Pedroni]

Hi.

> 
> Perhaps there needs to be a "strict" modifier to declarations that says
> whether merely checking for methods is sufficient or whether an explicit
> declaration is required. It should probably be up to a specific function
> whether it wants to use the first method of checking, or the second, or
> both. 
> 
> On the other hand, perhaps it is just extra complexity. If you wanted
> strict checking, wouldn't it be easy to implement an __check__ method
> that checked both the __interfaces__ AND the actual signature? Or you
> could require a method name like def __supports_readability__(): pass.
> 
> Python already has types and classes. I'm adding something that you call
> protocols. Michel is adding something that he calls interfaces. It makes
> sense to have type declarations that reference all four. It is important
> to me to simplify this model...
> 
Yes, this is overcomplicated to fit in python. But understanding
that there are in principle differences is important. [This is mostly
a repetion but ...]

- Your idea idea for unifying protocols and interfaces is to check
  both for isImplementedBy first and for signatures.
  
My opinion was that checking for interfaces should simply check isImplementedBy,
 why:
- because it makes sense for the interface philosophy (which OTOH
  has little to do with python plain old way-of-life).
- because checking just the signature in the case of tiny interfaces
  with few methods having inexpressive names make typechecking weak
  when that is not required. And this kind of interfaces
  are used and written (at least in java which is mainstream
  and have interfaces that resemble the proposed one).
- we can guarantee signature comformance at class def time.

Protocols: mostly needed to typecheck the std lib,
and is worth to notice that things like Mapping or Sequence
(because of type/class dicotomy) cannot be expressed really
as Michel Pelletier interfaces. They will be mostly predefined
or be very tiny, I see little chance that someone can positively
define new complex protocols outside the std lib tradition => we don't really
need a nice syntax to define them, an anonymous constructor can do the job,
or a function that take a class/interface and return the corresponding
protocol.

IMHO the point is that there is no need to weaken interface typechecking
(if we will have them) for the sake of protocols.

Hoping in the type/class unification we can live just with class,interfaces
and domains (something offering a __check__ for typechecking; if we agree
that checking for something like Prime makes sense), 
then we should simply offer a way to construct a domain that check 
for signatures (a "protocol" if we want).


regards.