[Types-sig] Interfaces API: a concrete contact point: more subtlities

[Samuele Pedroni]

Hi. I will not insist further.
This is my last try on the topic.

[Paul Prescod]
> 
> Samuele Pedroni wrote:
> > 
> 
> > > My code:
> > >     # if the object CLAIMS to support an interface, we believe it
> > >      if _findInterface(val, iface):
> > >         return 1
> 
> > Your code:
> >        if hasattr(val,'__interfaces__'): # or Michel Pelletier 
__implements__
> >          return _findInterface(val,iface)
> >        else:
> >          ...
> 
> Why would we return if it doesn't support the interface? I think we
> should go on to check conformance to the interface, even though the
> object doesn't DECLARE conformance to it. Python users have expressed
> that it is very important to them that objects that look like they
> conform should pass the type-checker.
If you reread the archive, at least in this discussion, I was the first
pointing out that, and speaking about "selectors" and similarity with Smalltalk
;). 

http://mail.python.org/pipermail/types-sig/2001-March/001153.html

Yes that's important, especially if one want to put checks 
everywhere in the stdlib, and in that case just the name of the method
is saying a lot (e.g. __getitem__) on the programmer intention like
it is in Smalltalk tradition. This is not so true for file-like methods
but if we are to restrictive we will make people unhappy.

But the interfaces as proposed by Michel Pelletier are there
to express complicated apllicative logic.

> 
> > ...
> > (A) is the right kind of "type checking" for the
> >  for-runtime-reflection-&-eventually-for-design-decisions-enforcing
> >  interfaces of Michel Pelletier proposal, which (I imagine) will
> >  carry a lot of implicit requirements
> > 
> > (B) express the plain-old python approach to protocols, it is mostly
> >  needed for "type checking" the std lib, and the checked things
> >  would be special __foo__ methods or having simple things like a 'read'
> >  or 'readline', but checking anything too much complex this way is expensive
> >  and does not make (IMHO) that much sense.
> 
> In my opinion, that is the beauty of putting them together. If a user
> claims to support the SocketServer interface, we trust them and they get
> a very efficient pointer check. Maybe we'll even get to the point where
> we check conformance to interfaces at class definition time so that
> trusting them is relatively safe.
AFAIK for very complicated things the actual way of life of python
is to furnish abstract classes, a SocketServer typecheck will
be a check against being an instance of a SocketServer class.

This may change once we have Michel's interfaces but if you're
writing something heavyweight putting an implements assertion
does not cost that much and could even make sense and in any case
is Michel Pelletier proposed philosophy, he want people doing that ;).

IMHO mixing the tradition of well-established at language
or lib level tiny  protocols: e.g. the special __magic__ methods and file-like 
objects, and the heavyweight new interfaces of Michel Pelletier with
this kind of default checking is just apparently clean.

With an imaginative and hyper-tentative syntax I think it would be better to 
have full control about what we want to check!

protocol PReadable # but we won't need that, better anonymous protocol   	 	
		   # constructors as Tim Hochberg proposed
 def read(size)
 
interface IStarTrekCompilerVisitor
 ...
 
interface IWorkerThread:
 
def input(in: PReadble) # check if 'in' has 'read'

def star_ast_visit(visitor: IStarTrekCompilerVisistor) # check isImplementedBy

and eventually 

def schedule(thread: IWorkerThread.loose) # check isImplementedBy or signatures
 ...
 
That's all from my part.

regards.

PS: 1) the idea about just checking for methods is mostly a workaround
to cope with actual tradition and to save people from having to 
put implements assertion in their old code, which would be even
unnecessary because if a class implements a special __spell__ method
is very likely at least trying to do the right thing.
2) Wanting to make typecheks is already breaking the similarity with Smalltalk 
;).
3) checking for signatures looking at Smalltalk way-of-life would require (in
principle) to check even for arg names, in Smalltalk they are part of
the selectors. But to have uniform args naming is not in python tradition :-(.

We are just trying to find a compromise, it should be a little bit ugly.