[Python-3000] Abilities / Interfaces: why not adapt()?

[tomer filiba]

adapt() is a "casting" mechanism, whereas generic functions are
dispatch mechanism (multimethods)... i'd guess there are some
overlapping characteristics, but they are different by concept. [1]

we can say interfaces are a subset of adaption (adaption > interfaces):
* interfaces are mostly static, where as adaption is dynamic
* interfaces only indicate compliance, adaptation resolves mismatches
* you can implement interfaces using adaptation (__adapt__ just checks
  for isinstance or some mechanism)

but comparing adaption to generic functions is apples to oranges.

suppose i have a function that logs text to a file:
def log(text, fileobj = sys.stdout):
    fileobj.write(text + "\n")

and for reasons like computation with side-effects, i want *early* detection
of errors (before side effects occur): i want to make sure fileobj has is a
file-like object. [2]

interfaces and adaptation solve this issue, but generic functions
are not applicable really. i mean, if i had a version of log() for
files, and another for lists as the backing store, i'd say
generic functions are the solution.

but all i asked for is an object that has a write() method, and for that
i don't want to require any multiple dispatch mechanisms.

besides, the use case of multiple dispatch is by far less common
than "i need to make sure the object i'm dealing with is what i expect"

= = = = = = = = =

as a bonus, type annotations go very well with adaption:

@adapting
def log(text : str, fileobj : file = sys.stdout):
     fileobj.write(text)

where the `adapting` deco takes the function's __signature__,
adapts all the arguments accordingly, and invokes the original
function with the adapted arguments. this way, all mismatching
types are detected prior to executing any code with side effects.

adaptions also doesn't require any best-fit algorithms, and is
easily extensible, as every argument can theoretically provide its
own "how-to-use-me" adapter.

and last but not least -- adaption is well suited for object proxies,
which would make RPyC's job easier :)


-tomer

[1] i know this pep has been killed, but i wanted to point out the
differences. if it's meant to stay dead, i won't bring it up anymore.

[2] i may also define a WritableFileProtocol for adapt, that makes sure the
file's open-mode allows writing. i mean, the object's interface may provide
a write() method (hasattr(fileobj, "write")), but i want to make sure the file
is open properly, etc.




On 11/21/06, Paul Moore <p.f.moore at gmail.com> wrote:
> On 11/21/06, tomer filiba <tomerfiliba at gmail.com> wrote:
> > adaptation is much more capable ("don't complain, do something
> > about it") and reflective (both the protocol and the instance can
> > perform the adaptation) so you don't have to explicitly inherit
> > from many base classes or interfaces.
> >
> > i'm very +1 on reviving adapt() and dropping all those "i want
> > strongly-duck-typed interfaces in python" talks.
>
> To some extent I agree, but I also think that generic functions are
> even more flexible. (As per the previous discussion which started
> covering adaptation and moved on to generic functions).
>
> I'd like to see some clear evaluation of the pros and cons of the 3 -
> interfaces, adaptation, and generic functions. My feeling is that they
> are to some extent "competing" proposals, and we need agreement (or
> BDFL ruling!) on which is the way forward, before we start discussing
> specifics.
>
> Paul.
>