[Python-3000] Adaptation vs. Generic Functions

Guido van Rossum guido at python.org
Fri Apr 14 14:55:45 CEST 2006


> Guido van Rossum wrote:
> > What if, instead of adding registries mapping types to functions left
> > and right (in pickle, copy, pprint, who knows where else), we had a
> > convention of adding __foo_bar__ methods directly to the class dict?
> > This would require giving up the effective immutability of built-in
> > types, which has widespread repercussions (mostly in the area of
> > multiple interpreters) but nevertheless if this was officially
> > endorsed, we could clean up a lot of type registries... (I notice that
> > I haven't really found any use for *multiple* dispatch in my few
> > explorations of @overloaded; that is, until the operator.add idea came
> > along.)

On 4/13/06, Ian Bicking <ianb at colorstudy.com> wrote:
> One advantage of using a function as the registry is that the function
> lives in a particular place.  A method only has a name, there is no
> namespace for it.  In addition to possible name collisions, functions
> are possible to backtrack.  If you want to know what some generic
> function specialization is about, you look at the original function
> definition, which you can find by following the imports.  If you want to
> know what a particular magic method is about, there's no particular
> technique to accomplish that.

I'm expecting that the probability of name collisions here would be at
the same order of the probability of module name collisions.  But I'm
not married to the idea; it's pretty wild as ideas go; and I'm not
sure we can solve the issues with sharing of builtins.

> >>I suspect this falls into the "wild ideas' category, but it's an
> >>interesting thought experiment anyway. Perhaps with relevance to other
> >>uses of generic functions.
> >
> > Definitely wild. Reader beware. Now is the time to generate lots of
> > wild ideas and let them sink in. If it still seems a good idea 3
> > months from now we may select it for a code experiment (as opposed to
> > a thought experiment). BTW I want to encourage lots of code
> > experiments for Python 3.0 -- though not directly in the p3yk (sic)
> > branch.
>
> And I could have sworn you asked for less wild ideas just the other day...

Um, yes. I want wild ideas quickly proposed so they can quickly be
shot down, or not. I do *not* want extended arguments (like we've seen
too many) where proponents of a proposal attempt to defend it at all
cost. I'm still very skeptical of new statement forms or new
paradigms.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list