[ANN] Multimethod.py -- multimethods for Python

[Tim Peters]

[posted & mailed]

[Neel Krishnaswami]
> [This is a repost, since the original apparently never made
>  it; if you see it twice, my apologies.]

This is the only one I saw.  Thanks for reposting it.

> I'd like to announce the existence of Multimethod.py, a package
> that implements real (eg, CLOS/Cecil/Dylan) multimethods for
> Python.
> ...
> You can find it on my webpage at:
>
>   <URI:http://www.sff.net/people/neelk/open-source>

I posted a (unsurprisingly!) similar pkg about 5 years ago, modeling Cecil's
dispatching rules in Python.  It drew a grand total of 0 responses, so
you're *already* doing infinitely better than I did <wink>.

Can't say I was surprised -- few people had thought about multimethods then.
They're better known now, but also much easier to get at via Dylan now
(which people should definitely look into if they like what they see in your
emulation).

> ...
> (Incidentally, is this the sort of thing that should go on the
> types-sig?)

Generally, I'd say yes, but it's certainly welcome on c.l.py too.

The current incarnation of the Types-SIG has "a single specific goal: to
develop an optional static typing system for Python", and a discussion of
multimethods may be seen as defocusing (it wouldn't by me, but then the
Types-SIG has its hands full regardless these days so it wouldn't get any
mind share).  John Skaller posted a short piece about multimethods late last
year to the SIG, but it got buried under the static-typing traffic.

BTW, the surest way to kill any discussion in the Python world has
traditionally been to post some code <0.5 wink -- there is A Serious Theory
that the *last* incarnation of the Types-SIG self-destructed because Jim
Fulton implemented his ideas!>.

it's-a-strange-and-altogether-not-entirely-undisgusting-
    world-ly y'rs  - tim