[Python-Dev] Son of PEP 246, redux (original) (raw)

Michael Walter michael.walter at gmail.com
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 . What am I missing?

Sleepingly yours, Michael

On Wed, 12 Jan 2005 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

More information about the Python-Dev mailing list