+ Even in Cecil, which was designed from the ground up to support MMs,
Chambers stresses repeatedly that a graphical programming environment
is vital (his word) to keep the programmer's view of the world
manageable. "Traditional programming environments are text-based, and
text is particularly bad at showing non-hierarchical relationships ...
[in the Cecil system] programmers would never need to look at a flat
textual form of a Cecil program." MMs cut across classes in arbitrary
ways, and there simply isn't any "good" place to put them in the
"flat file == Module == major class" editor-based style of Python
development we all use today.
+ Even in Cecil, which has a great deal of static type info available at
compile time, decent speed requires sophisticated profile-based
feedback to the compiler, specifically aimed at speeding MM-style
dispatch searches. And these are under rules simpler than the ones
Marc sketched out so well (no coercions, no provision for saving a list
of less-specific MMs).
I hasten to add that I _like_ MM's! They're an achingly natural
generalization of single dispatch, and are clearly very useful in some
(though possibly relatively few) contexts. I just don't think they're
ready for prime time yet, & especially not in a language never designed
to accommodate them.
So if Guido is willing to change the way the special methods work, I urge
sticking to the "simple Python-like" hacks we've been discussing: they
solve problems people actually have in Python practice, in ways that
fit well with Python's current worldview, and don't introduce either new
conceptual complexities or new runtime cycle sinks (to the contrary, most
of the suggested changes simplify the programmer's view of the world, &
some even speed things up). Pragmatic responses to pragmatic concerns.
OTOH, MM's can more-or-less be simulated "by hand" today, and I'd like to
continue developing a Python implementation in that mode. The end result
may be useful for its own sake, and the effort will surely suggest ways
to improve Python (e.g., the type system reflects the C implementation
more than the programmer's view of the world, and in sketching out an
efficient way to do MM dispatch I stumbled into the sometimes-brought-
up-in-other-contexts gripe that there's no clear way to go from a class
to the classes that derive _from_ it today ... stack up enough solutions
to little-but-deep problems like that, & MMs would be a whole lot easier
to graft on ...).
passionately y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp