PEP Proposal

Carl Banks pavlovevidence at gmail.com
Thu Sep 25 18:30:11 EDT 2008


On Sep 25, 4:04 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Thu, 25 Sep 2008 16:24:58 -0300, <python-... at arcor.de> escribió:
>
> > sorry, I have these ideas for longer than 10 years, please have a look  
> > on it
> > and comment on it. Thx.
>
> > This is another proposal for introducing types into Python.
>
> You got the terminology wrong. Python had "types" from the very start.  
> You're talking about some kind of generic functions, or an alternative  
> dispatch method.
>
> Read this GvR blog post [1] and his next one; also see PEP 3124 by Phillip  
> J. Eby, who wrote a pretty good implementation of generic functions a long  
> time ago.
>
> Your proposal requires a syntax change and three new keywords; all the  
> others achieve roughly equivalent results without requiring any change to  
> the core language.


Just to play Devil's advocate here, multimethods(**) aren't
equivalent, roughly or otherwise, to what the OP is requesting.
Superficially it looks that way, but the actual use case for this
logic programming is something that ordinary multimethods can't do.

Prolog-style programming is sort of the exact opposite of pure
functional programming.  Whereas in pure functional programming there
are no side effects, in Prolog pretty much everything is a side
effect.  The way things happen in Prolog is execution of side effects
in the process of searching for pattern matches.

A decent multimethod implementation doesn't use trial and error for
dispatch; it'll use some kind of mapping and cacheing to get to the
appropriate function as quickly as possible.  In logic programming
however, the trial-and-error is essential since side-effects can and
are supposed to happen in the process of trying.


Anyway, this proposal can easily be implemented more or less as
proposed without any syntax changes, using the same ideas as the
multimethod implementations, but guaranteeing trial-and-error
dispatching.


Carl Banks

(**) I avoid the term "generic function" since it constrasts starkly
with the use of the word "generic" in generic programming.



More information about the Python-list mailing list