14 comments

[ 2.3 ms ] story [ 51.5 ms ] thread
I understand that language design is hard, but this does seem to be a crippled version of Clojure's multimethods. http://clojure.org/multimethods

And arguably, they're not powerful enough either.

Welcome to Python in the 21st century, bolting on crippled versions of functionality that other languages support natively. But I guess that's the price you pay to evolve a popular language. See also C++ and Java.
That's it, basically. You have to implement this things through an ugly decorator thing because you just can't touch the syntax too much, or we would have another Python3 situation.
Clojure basically borrowed the multiple dispatch from Common lisp. So, they have been in existence since past 20+ years now.
You can also draw parallels with Go's approach to interfaces, and Go is not the pioneer in using this approach. Or you can draw parallels with extension classes in C# or Scala.

This is a sort of pretty common stuff, imho. Not some crown jewel Python has snatched from a unique language that was the only one to implement it.

I use Python since ~1999, and had a chance to observe how the language has imported a number of approaches from other languages, usually to a great benefit of its users. This is one more step. Note how it does not introduce a single bit of new syntax or backward incompatibility, btw.

Actually, you're right. Python's functionality is pretty close to C#'s. Clojure just happens to be the language that introduced the concept of non-single-class polymorphism to me.

Rich Hickey's pretty open about the fact that there's very few original ideas in Clojure. When he presented the new reader/EDN features of Clojure 1.4, someone in the crowd told him it was very similar to YAML. He said "I didn't know that, I ripped it off Erlang, but I'm sure other people have had the same idea." (words to that effect)

For what it's worth, PyPy had a multimethod implementation that it used to power some of the more polymorphic builtin functions in Python. They recently started killing them off as too difficult to reason about and maintain.
Interesting, I just took a look. I can see three main differences with Clojure:

# You can only dispatch on the class of all arguments. # You can't prefer one method over another. # You've got to use the Python class hierarchy.

I suspect the last one is the real killer: you can't detangle yourself from Python classes, and it doesn't interact well with the Python class system. Idiomatic Clojure code, on the other hand, treats classes as a necessary evil in extremely limited circumstances and allows you to construct arbitrary hierarchies.

All of which is insight that helps explain to me why the Python implementation looks so limited to me. Language design is hard, especially when you're popular.

> If the last sentence read to you like some Haskellish solution to a self-inflicted problem,

Language design is a formal discipline. Why the urge to dumb it down?

Exactly, there is a tendency among dynamic language proponents to think that programming in a statically type checking language is masochistic.
When that is all that was taken away from a detailed and well written technical article, it is easy to see the problem with language tribalism.

    That's a joke, son.
       --F. Leghorn
It also illustrates the danger for authors of leading with a joke at someone else's expense. All that effort to carefully explain the ideas, why they are valuable, and how they can be used gets collapsed into a religious dispute over type safety.
Considering the fair amount of FP stuff in Python in general, and certain parallels with Haskell in particular (not only e.g. comprehensions, but even the significant whitespace), the joke does not look snarky — at least, to me.
This hardly even saves any LOC over the original two versions, and requires the reader to understand these new annotations. This is what happens when programmers get obsessed with some arbitrary notion of "elegance": they fiddle with the fundamental semantics of a language to save a couple lines of code and end up with an unreadable mess of cute tricks piled on cute tricks.

If only Python supported multi-line lambdas...