[Python-Dev] type categories

[Greg Ewing]

David Abrahams <dave@boost-consulting.com>:

> This concern seems most un-pythonic to my eye, since there are already
> all kinds of ways any module can change the behavior of any call in
> another module.

Yes, but most of the time you don't have to use them!
With this feature, it would be the *normal* way of using
it.

> forcing all the definitions to be in one place prevents an important
> (you might even say the most important) use case: the author of a new
> type should be able to provide a a multimethod implementation
> corresponding to that type.

You can get that without the notion of a generic function as a
separate entity. Just have a dispatch mechanism that looks in all the
arguments of a call for a method to use, instead of just the first
one.

That would be relatively tractable, since at least you'd know that the
method must be found in one of the argument classes somewhere.

It also doesn't suffer from the who-imports-the-module problem, since
someone must have imported it in order to get an object of that class
in the first place.

The use case that this doesn't cover is where you're not defining a
new class, just trying to add behaviour to handle a previously
unanticipated combination of existing classes.  The organisational
problems involved in that aren't unique to Python, and seem to me an
inherent feature of the problem itself. Where does functionality
belong that isn't owned by any class?

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+