Weblogs Forum - Five-minute Multimethods in Python

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Five-minute Multimethods in Python

24 replies on 2 pages. Most recent reply: Jan 14, 2013 12:56 AM by Tyler Shopshire

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

has

Posts: 15
Nickname: has
Registered: Nov, 2004

Re: Five-minute Multimethods in Python

Posted: Apr 2, 2005 3:18 PM

Reply

Advertisement

> The longer I think about the MultiMethod pattern the less
> convincing I find some details of it's implementation
> especially the usage of typemap.

As I say in my earlier post, Guido's five-minute implementation falls well short of a true multimethod system. (It's probably disingenuous to refer to it as 'multimethods' at all, but personallly I'll leave that argument to the language lawyers.;)

To be honest, I'm not sure of the practical value of creating either a partial or full multimethod framework for Python. While not as compact or elegant, traditional patterns for achieving equivalent ends in single-dispatch languages do have the advantage of being well defined and well understood and familiar to anyone else that reads it. As a rule I think it's better to go with the natural flow of a language (or switch to another one) than start picking fights with it; e.g. I hate using multiple inheritance to do mixins, but since MI is what Python provides I'll use it over creating my own mixin system any day.

Cheers,

has

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Five-minute Multimethods in Python

Posted: Apr 2, 2005 5:25 PM

Reply

(About honoring subclasses a la isinstance.)

> Unfortunately I don't see a possibility to change the
> pattern without blowing up the lookup-time from constant
> to linear in the number of registered type-tuples.

Oh, that can be taken care of with a cache quite easily.

The problem is when you have two possible matches, one of which is exact in the first argument and matches a subclass in the second, and one the other way around. Which one to pick? That's why *real* multimethods are quite subtle.

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Five-minute Multimethods in Python

Posted: Apr 2, 2005 11:57 PM

Reply

> (About honoring subclasses a la isinstance.)
>
> > Unfortunately I don't see a possibility to change the
> > pattern without blowing up the lookup-time from
> constant
> > to linear in the number of registered type-tuples.
>
> Oh, that can be taken care of with a cache quite easily.

o.k.

> The problem is when you have two possible matches, one of
> which is exact in the first argument and matches a
> subclass in the second, and one the other way around.
> Which one to pick? That's why *real* multimethods are
> e quite subtle.

Yes, no natural partial order on cartesian products exists that would solve this ambiguity issue. Our world would be much simpler if we consider it as a 1-dimensional line and all our cognitive abilities were based on regex search... A C++ compiler produces warnings/errors in case of ambiguity. The register() function could do so too. It would accept a cartesian product type AxB in presence of another product A'xB' if one of the following conditions hold:


1) A'<=A and B'<=B
2) A<=A' and B<=B'
3) A and A' or B and B' are unrelated i.e. neither
   A<=A' nor A'<A is valid ( or not B<=B' and not B'<B )

Registering another function would have to check this conditions for all available products.

Regards,
Kay

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Five-minute Multimethods in Python

Posted: Apr 3, 2005 12:16 AM

Reply

> > The longer I think about the MultiMethod pattern the
> less
> > convincing I find some details of it's implementation
> > especially the usage of typemap.
>
> As I say in my earlier post, Guido's five-minute
> implementation falls well short of a true multimethod
> system. (It's probably disingenuous to refer to it as
> 'multimethods' at all, but personallly I'll leave that
> argument to the language lawyers.;)

I think all those attempts are musings about the problem of adding meta-data to Python in the form of type information. Unfortunately concentrating on the behavioural aspects i.e. duck-typing is also not enough because a failure in provision of a certain interface could be a well accepted behaviour, caught by an exception. This is very common. So everything becomes optional and we should be clear about what is working and what doesn't. Since typechecks are used and many programmers create their own typechecking-frameworks, good pattern are important.

Regards,
Kay

Julian Smith

Posts: 1
Nickname: cgdae
Registered: Apr, 2005

Re: Five-minute Multimethods in Python

Posted: Apr 4, 2005 5:03 PM

Reply

> The problem is when you have two possible matches, one of
> which is exact in the first argument and matches a
> subclass in the second, and one the other way around.
> Which one to pick? That's why *real* multimethods are
> e quite subtle.

I wrote a proposal for adding multimethods to C++ [*], and its approach to this problem was to mimic what C++ does for compile-time dispatch: each parameter of the winning match must be as good or better match than the equivalent parameter of all other matches. Otherwise it's an 'ambiguous dispatch' error.

How does that sound for python? I guess there's more use of multiple inheritance, but the approach should still be applicable?

I think that Common Lisp treats earlier parameters as more important, so never has this problem, but this doesn't seem very elegant to me.

[*] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1529.html

- Julian

Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Five-minute Multimethods in Python

Posted: Apr 4, 2005 7:33 PM

Reply

> I wrote a proposal for adding multimethods to C++ [*], and
> its approach to this problem was to mimic what C++ does
> for compile-time dispatch: each parameter of the winning
> match must be as good or better match than the equivalent
> parameter of all other matches. Otherwise it's an
> 'ambiguous dispatch' error.
>
> How does that sound for python?

Perfect!

> I guess there's more use
> of multiple inheritance, but the approach should still be
> applicable?

Oh, I don't know. MI isn't all that popular in Python either.

Phillip J. Eby

Posts: 28
Nickname: pje
Registered: Dec, 2004

Re: Five-minute Multimethods in Python

Posted: Apr 5, 2005 11:01 AM

Reply

> > I wrote a proposal for adding multimethods to C++ [*],
> and
> > its approach to this problem was to mimic what C++ does
> > for compile-time dispatch: each parameter of the
> winning
> > match must be as good or better match than the
> equivalent
> > parameter of all other matches. Otherwise it's an
> > 'ambiguous dispatch' error.
> >
> > How does that sound for python?
>
> Perfect!

You might already realize this, but that rule is exactly the same as logical implication. (i.e., what PyProtocols does for predicate dispatch). A type tuple implies another type tuple only if each type is the same or more-derived. If only one of two type tuples implies the other, then it's more specific. If you define a generic function using only 'isinstance()' tests on original arguments in PyProtocols, then you will get exactly this behavior.

Interestingly, the original definition of predicate dispatch in the Chambers & Chen paper is that it's actually the same as multimethod dispatch, but with pseudo-parameters for arbitrary expressions, and treating "True" and "False" as pseudo-classes for the result of logical expressions.

Of course, the devil is definitely in the details. :)

Malcolm Sharpe

Posts: 1
Nickname: masharpe
Registered: Apr, 2005

Re: Five-minute Multimethods in Python

Posted: Apr 8, 2005 10:52 PM

Reply

I implemented a similar interface for multimethods recently, but it was a little more elaborate. I don't think this multimethod syntax is very Pythonic: when the reader sees foo(a,b), the reader expects a function call, not a method call. To my eyes, (a,b).foo() would be a more transparent syntax for multimethods; it's clear that foo is dispatching on the types of both a and b. On the other hand, it's ugly, and incompatible with Python as it stands now (an implementation would have to look something like DispatchOn(a,b).call('foo')). A compromise might look like a.foo(b), where it's clear that a method call is occuring, even if it isn't clear that it's dispatching on the type of b. It's also possible to implement it, although it's limited to pure Python classes.

Luckily, I haven't yet encountered a situation where I needed multimethods, so I'll stick with single dispatch.

Michael Drumheller

Posts: 1
Nickname: drumheller
Registered: Jun, 2005

Re: Five-minute Multimethods in Python

Posted: Jun 4, 2005 1:11 AM

Reply

Has anyone seen David Mertz's contribution, described here http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html
and/or here http://gnosis.cx/publish/programming/charming_python_b12.html ?

I'm in the middle of trying it out, and it seems pretty nice. Does not use decorators but could probably be made more concise with them.

MD

Tyler Shopshire

Posts: 1
Nickname: xshoppyx
Registered: Jan, 2013

Re: Five-minute Multimethods in Python

Posted: Jan 14, 2013 12:56 AM

Reply

Apologies for bringing up a reviving a really old post, but a bug hit a friend of mine whom I had recommended to this blog post. Instead of only passing *args, it should be changed to pass *args and **kwargs. This is subtle and I'm guessing doesn't affect 95% of the people that would use this code, but I'd recommend changing if it is possible. Thanks, this was a good read!

Flat View: This topic has 24 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use