generic functions coming to python?

by anders pearson Thu 06 Apr 2006 15:06:35

About once a year or so, I find myself spending some time immersing myself in the world of Lisp (and Scheme). Lisp is sort of a proto programming language. Lisp fans make a strong argument that it's on a different level entirely than all other languages. I pretty much buy into that argument, but I've never quite been able to get it to click for me to the point where I would feel comfortable writing a real, production application in Lisp. I always start out with the intention of writing something useful and large enough to get myself over that hump but I always either get distracted with other stuff or hit some wall (usually involving just not being able to get some library I want to use installed on whatever Lisp interpreter I've chosen).

Nevertheless, my little excursions into the land of parenthesis have always been worthwhile. It always seems that I pick up some new or deeper understanding of some aspect of programming. When I first went through the exercises in SICP it was a revelation for me. Suddenly all kinds of things like recursion, first-class functions, data driven programming, and constraint systems made much more sense. Later attempts taught me the power of code as data, having full, unrestrained access to the abstract syntax tree of your running program and the power of a true macro system (I still don't feel comfortable with Lisp's macro syntax but I've at least decided that it's worth learning at some point). Scheme was also my first real exposure to a proper, interactive REPL environment and that style of development impressed me enough that when python came along, I was probably more willing to give it a look because it had a nice interactive interpreter. Common Lisp and SLIME are still the gold standard in that department though.

Lisp certainly isn't the only language that I've learned valuable lessons from though.

Still, Lisp remains the wellspring of mindbending "AHA!" moments for me. My most recent delving into Lisp was with Peter Siebel's book "Practical Common Lisp". On that last pass through, generic functions finally clicked for me and I was able to seem them as the conceptual underpinnings of object oriented programming. Suddenly, things like aspect oriented programming and python's decorators were just trivial applications of this one root idea.

Now, I see that Guido's thinking about adding generic functions to python 3000. Clearly, I think this is a good idea and I'm really curious to see how the syntax comes out. PJE's implementation in PEAK is interesting, but having it in the syntax of the language should allow it to be even smoother.

TAGS: programming python generic functions lisp


It's probably going to look very much like RuleDispatch (PJE's package), and so without any extra syntax. I haven't actually seen anyone suggest any syntax during the discussions; what we have seems to work well, and decorators are spif.

I've gotten very enthusiastic about the 'with' statement in python, and while reading the PEP, there's a discussion about how hiding flow-control can make code 'inscrutible.' I'm afraid a full generic functions implementation will make too many ways to hide flow-control (e.g. doIt.when).

So even though, I agree generic functions are the general case, 'my python' wouldn't have it.

I enjoyed reading your posts and the info. I imagine that you get a lot of this but could you spare a Orkut invite?

Whoa..Im not a programmer of sorts like that but I do like the verification add....would you be interested in a php project? Im the one who asked about the invite earlier but this is some good stuff. Seen some others on RAC. Thx...

Can you talk more about why you feel enterprise approaches to software design tend to be misguided? In my limited experience with enterprise stuff, it seems like the modularity makes refactoring fairly straightforward.

I have a whole other blog post planned at some point to go through Erlang's concurrency mechanisms and explain how it all works and highlight the parts that are counterintuitive at first.

Basically, typical "enterprise" systems attempt to get reliability and robustness with a heavyweight approach: buy big, high end, expensive servers, run Oracle on them, and use layer upon layer of abstraction, relying on checked exceptions and static typing to try to catch all your errors at compile time.

Meanwhile, Erlang makes it easy to get nine nines of uptime on clusters of tiny memory constrained embedded systems running a weakly typed, dynamic language and focusing on extremely simple architectures based on functional programming and where processes are expected to die loudly and quickly as soon as they encounter anything unexpected. Somehow they're able to get all the advantages of rapid application development with very short line counts, readable, modular code, fast edit/compile/run cycles (Erlang even lets you replace a module in place in a running server process without restarting or even having it miss a single request), complete lack of xml situps, etc. yet it still achieves uptime to make j2ee developers jealous with performance comparable to C (spawning an Erlang process takes fewer cycles than calling a function in C on many processors).

But like I said, this is all for another post later.

I think that Python does have some disadvantages. Python is not as well established as Perl, so it has fewer libraries to choose from, and is more susceptible to changes in the language. Python also tends to be a bit slower than Perl.

I myself thought too that adaptation would be more useful but Guido's article did convince me of the opposite with a simple example. Now I'm really curious to see generic functions applied in practice.

formatting is with Markdown syntax. Comments are not displayed until they are approved by a moderator. Moderators will not approve unless the comment contributes value to the discussion.

remember info?