The parametrized version of the pass keyword could be used to indicate a formal interface. <br><div><span class="gmail_quote">On 07/12/06, <b class="gmail_sendername">Dave Anderson</b> &lt;<a href="mailto:python3000@davious.org">
python3000@davious.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Has-Method Contracts<br>--------------------
<br><br>The first thing I loved about python (coming from java), was this<br>realization that I was no longer need be caught up in the inheritance<br>game.&nbsp;&nbsp;If I wanted to use an unspoken convention that I could get a<br>
special string from every object just by defining name() in each of<br>those objects, that's all I had to do.&nbsp;&nbsp;It didn't matter which class<br>tree it came from.<br><br>Looking at the syntax sketch, this can be formalized; but, its a low
<br>level of formality that fits the context.<br><br># (I used <a href="http://Generic.name">Generic.name</a> in my original post, but that was a mistake.<br>#&nbsp;&nbsp;Sorry for my confusion, Phillip)<br><br>def get_name(arg: AnyClass.name
):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # AnyClass will magically have<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return arg.name()&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # a reference to any method name<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# somehow<br><br>further refinement of this would be:<br><br>class HasName:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def name(self):<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br><br>def get_name(arg: HasName):<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return arg.name()<br><br>but this refinement (in the syntax sketch), would force implementers to<br>declare the following implementation:
<br><br>class X:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implements HasName<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def name(self):</blockquote><div><br>I may be missing something here, but we already have a mechanism for
defining that a object defines certain methods. Could we not keep it
orthogonal and have, e. g.:<br>
<br>
class super():<br>
&nbsp;&nbsp; def __init__(self): pass<br>
<br>
&nbsp;&nbsp; def typeOfSuper(self): pass(subclass) <br>&nbsp;<br>The way pass is defined now would remain the default. A new builtin pass() would be added to support your notion of interfaces.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Has Class-specific Method Contracts<br>-----------------------------------<br><br>Similar to Has-Method Contracts are class-specific method contracts.<br>This is when you use a well-defined class as a way to indicate the<br>
context of a method and separate it from homonyms.<br><br>def add_key_value_pair(arg: MutableContainer.add, key, value):<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;arg[key] = value</blockquote><div><br>def __add__(self, onemore): <br>&nbsp;&nbsp; MutableContainer.add
 (self, onemore.key, onemore.value):<br>&nbsp;&nbsp; <br></div>If you need more than one function to implement '+', you can use two classes.<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Implement (As a) vs Inherit (Is a)<br>----------------------------------<br><br>This is nuanced.<br>Basically, if I have some object Car and I want to be able to use it<br>like a dict, I don't necessarily consider it inheriting from dict (or
<br>even UserDict).&nbsp;&nbsp;That is, I don't think a Car is a dict.<br><br>To me, even if Car happens to represent a dict by being able to be used<br>as a dict, the expression of this fact feels better expressed as merely<br>implementing dict.
<br><br>compare:<br><br>class Car(dict):&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# car... is a dict? hmm, a bad ring to it<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br><br>class Car:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implements dict # oh, Cars can be used like a dict, got it<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br><br>In addition to that subjective differentiation, there is a technical
<br>argument.&nbsp;&nbsp;Without something like an implements declaration, if I ever<br>want to express a relationship to another class, but with different<br>internals, I am forced to first define an abstract class and then<br>inherit from that.&nbsp;&nbsp;With an implements declaration, I can say implements
<br>dict and be free of inheriting any of its internal implementation.<br><br>(I concede here that I could, in fact, inherit UserDict, override all<br>the methods, and just not call super in my init.)<br><br>Even with the nicely done ABCs, is there an easy way for a class to
<br>declare that it can be used like a dict with its own implementation of<br>dict methods?&nbsp;&nbsp;With this syntax sketch, UserDict would remain the same<br>except:<br><br>class UserDict:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implements dict&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # dispatch can rely on this declaration
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; # rather than method-checking<br><br><br>The Consequences of Going Outside of the Hierarchy<br>--------------------------------------------------<br><br>For all the above reasons, I want to see python support something more
<br>flexible than type-based dispatching.&nbsp;&nbsp;We can look at the method-scoped<br>units of Implementations as a limited version of Guido's Abilities, and<br>we can look at the class-scoped implementations as types, or classes, or
<br>&nbsp;&nbsp;also as abstract interfaces from concrete classes.<br><br>Unfortunately, I am now outside of the hierarchy tree; an implementation<br>tree would be a superset of a class's hierarchy tree.&nbsp;&nbsp;I suppose that<br>using dispatch this way is more complex compared to a strict class-based
<br>set of relationships (because I am asking for checks not just on the<br>class-tree, but also on the implementations off that class-tree); but,<br>I'd rather fold current python usage into a future of type /<br>protocol-aware methods than force current pythonists into choosing
<br>between class or no class, to type or not to type.<br><br><br>(Small Caveat:) Using Implementations as a Development Tool<br>------------------------------------------------------------<br><br>Btw, if we formally differentiate that I'm declaring an implementation
<br>(versus inherit and override), I could programatically double-check my<br>implementation with tools...<br><br>class A:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;implements Container<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;def len(self)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br><br> &gt;&gt;&gt; interface_compliance(A)
</blockquote><div><br>This would just scan for a&nbsp; parametrised &quot;pass&quot; keyword and check that all subclasses inheriting from it implemented that method.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(If I missed the gist of these questions.&nbsp;&nbsp;Please forgive me and clarify<br>them for me.)<br></blockquote></div><br>Ditto for me.<br>-- <br>Cheers,<br>Hasan Diwan &lt;<a href="mailto:hasan.diwan@gmail.com">hasan.diwan@gmail.com
</a>&gt;