[Types-sig] Interfaces API: a concrete contact point: more
subtlities
Paul Prescod
paulp@ActiveState.com
Fri, 16 Mar 2001 07:53:12 -0800
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.
> ...
> (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.
On the other hand, if a user just has an object that is eqiuvalent to a
SocketServer but they haven't actually tagged it with the interface,
that will be relatively safe also.
Anyhow, I don't have to merge Michel's syntax explicitly. Maybe I can
convince you that in the closed world of my proposal, the proposed
algorithm makes sense and then extension to Michel's world can proceed
later.
We will allow the definition of relative expensive checks. Even the
checks for certain methods will be relative expensive. Therefore it
makes sense to allow objects to say: "I know that I conform to this
protocol. Don't bother to do the expensive check." The simplest way to
do this sort of thing is pointer equality with the protocol object.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.activestate.com/pythoncookbook