Q: Python 2.0 preliminary features?

[Amit Patel]

 skaller  <skaller at maxtal.com.au> wrote:
| 
| 	Hmm. I'm not so sure. Viper uses 'multiple dispatch' in the
| sense of doing case analysis on argument types. For example,
| to execute python's 
| 
| 	a + b
| 
| it checks the types of a and b, may coerce the arguments,
| and then calls an appropriate function.
| 
| Now, the cases I handle are fixed (int, string, sequence ..),
| but it would be interesting to ask: if I add a new type
| to the language, how can I incorporate it into the
| dispatcher?

Let's do a thought experiment:

Suppose I start out with int and float as my basic numeric types.  The
system provides int+int int+float float+int float+float (4 functions =
number of types^2)

Now Tim gives us a rational module.  He gives us int+rational
rational+int float+rational rational+float rational+rational (now 9
functions = number of types^2).

Unaware of Tim's bold move, Gordon gives us a long module.  He gives
us int+long long+int float+long long+float long+long.

Unaware of both Tim and Gordon, Barry gives us a complex module.  He
gives us int+complex complex+int float+complex complex+float
complex+complex.



Taken separately, each module is great.  It defines the new type's
interaction with the built in numeric types.

But together, who defines what it means to do complex+rational?  There
are gaps in the dispatch table.  If gaps lead to coercions, who
decides if complex can be coerced to rational or if rational can be
coerced to complex?

With multiple dispatch it seems like you can't combine independently
written modules without writing some "glue".  The person using the
modules may not be qualified to make those decisions.  :-(

	- Amit