[Python-Dev] Son of PEP 246, redux

Thu Jan 13 06:01:14 CET 2005

> instead interfaces can be defined in terms of individual operations, and 
> those operations can be initially defined by an abstract base, concrete 
> class, or an "interface" object.
I think this is quite problematic in the sense that it will force many
dummy interfaces to be created. At least without type inference, this
is a no-no.
Consider: In order to type a function like:
def f(x):
 # ...
 x.foo()
 # ...
...so that type violations can be detected before the real action
takes place, you would need to create a dummy interface as in:
interface XAsFUsesIt:
 def foo():
 pass
def f(x : XAsFUsesIt):
 # ...
...or you would want type inference (which at compile time types x as
"a thing which has a 'nullary' foo() function) and a type system like
System CT.
Former appears cumbersome (as it should really be done for every
function), latter too NIMPY-ish <wink>. What am I missing?
Sleepingly yours,
Michael
On 2005年1月12日 23:48:47 -0500, Phillip J. Eby
<pje at telecommunity.com> wrote:
> At 11:26 PM 1/12/05 -0500, Clark C. Evans wrote:
> >Regardless,
> >getting back to the main goal I had when writing PEP 246 -- your
> >alternative proposal still doesn't seem to provide a mechanism for
> >component developers to have a dialogue with one another to connect
> >components without involving the application programmer.
>> Eh? You still have adapt(); you still have adapters. The only difference
> is that I've specified a way to not need "interfaces" - instead interfaces
> can be defined in terms of individual operations, and those operations can
> be initially defined by an abstract base, concrete class, or an "interface"
> object. Oh, and you don't have to write adapter *classes* - you write
> adapting *methods* for individual operations. This can be done by the
> original author of a class or by a third party -- just like with PEP 246.
>> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com
>