Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Robert Kern <robert.kern at gmail.com> writes:

>> The problem with Python's model is that you
>> have to wait for a rather centralized process to agree on and
>> implement such a feature.

> No, you don't. Philip Eby has been working on various incarnations
> of generic functions for some time now. The only thing new with 3.0
> is that they may be included in the standard library and parts of
> the rest of the standard library may use them to implement their
> features. Implementing generic functions themselves don't require
> anyone to convince python-dev of anything.

>   http://python.org/pypi/simplegeneric/0.6
>   http://peak.telecommunity.com/DevCenter/RulesReadme

The first one doesn't do multiple dispatch.  I'll have to have a look
at the second one.  It looks interesting.  This link

   http://www.ibm.com/developerworks/library/l-cppeak2/

shows PEAK being used to do multiple dispatch based on predicates, but
the code to implement the predicates is in strings!  Sure, if you
don't have macros, you can always use eval instead if you have it, but
(1) doing so is ugly and dangerous, and (2) it's inefficient.  Lisp
implementations these days do fancy stuff (multiple dispatch, etc.)
implemented as macros and yet typically end up generating code that
runs within a factor of 2 of the speed of C code.

In addition to having to code predicates in strings, using PEAK seems
syntactically rather cumbersome.  Macros would help solve this
problem.  Decorators seem to help to a large extent, but they don't
help as much as macros would.

Thanks for the pointers.

|>oug