[Python-3000] Adaptation vs. Generic Functions

Ian Bicking ianb at colorstudy.com
Thu Apr 13 18:38:01 CEST 2006


Guido van Rossum wrote:
> Around the same time I also had this scary thought:
> 
> 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.)

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 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...

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Python-3000 mailing list