Halfway

Well, it’s actually a little more than halfway through the actual conference, but things have a sort of halfway feel for me. Today I did my presentation on generic functions, and I think I did okay. A small crowd of people gathered outside afterwards, surrounding Guido and I as we talked about generic functions and adaptation. Although he had only caught half the presentation and disclaimed his current state of “brain fry”, he nonetheless zeroed in on several very sharply insightful questions about the applicability of the technique. In particular, he was concerned that latent ambiguity in corner cases could bite users unexpectedly if those cases weren’t exercised by tests. I reassured him that it’s possible to create a PyChecker-like tool to spit out a list of possibly ambiguous or uncovered cases, as the original Chambers & Chen algorithm was designed to allow a compiler to spit out such a report at compile time.

Guido also seemed keenly interested in feedback from actual users, which alas I could not supply. Nevow’s Donovan passionately described his use cases for replacing adapters with generic functions, but there was a bit of a communications mixup at one point. He started explaining a game/simulation use case of “hack with broadsword against +1 shield” or something like that, and Guido thought it was some kind of strange metaphor rather than a literal use case. I guess now I don’t feel so bad that he usually thinks I’m saying something much more complicated than I actually am. 🙂

So many people were interested that we had to adjourn to an open space, which was nice because I got to explain a lot of the implementation pieces of generic functions, and talk more about use cases and future directions.

I also caught up with Bob Ippolito today, to let him know that a first draft of the Python Eggs runtime is now in CVS. There are several “polish” items that need to be done on it, including documentation, but it’s now where we could actually bundle it into an egg, and write up some short instructions like this:

1. Download setuptools-0.1.0-py2.3.egg or setuptools-0.1.0-py2.4.egg, as appropriate for your Python version.
2. Edit your setup.py, changing “from distutils.core import setup” to “from setuptools import setup”
3. Add a line to the top of the setup.py, saying “import sys; sys.path.insert(0,‘setuptools-0.1.0-py2.3.egg’)”
4. Run “setup.py bdist_egg” to build an egg file for your package, which others can then use by putting it on their sys.path or PYTHONPATH

That’s it. All we need to do is actually build the setuptools eggs. Right now, you can check setuptools out of the Python CVS sandbox, and run bdist_egg on it to get an early version. I don’t actually want to offer it for download in .egg form until we get the rest of the API finished and it can handle all the corner cases, like OS X library relinking (hint, hint Bob 😉 ). But even in its current state, it’s already close to being the easiest way to distribute and install Python packages in binary form, so much so that I expect that building an egg from a source distribution will become the preferred way to get a package for a platform that the author doesn’t have. (Of course, eggs containing only Python code and no C are cross-platform, and that will certainly be the case with the setuptools egg.)

So eggs are sort of half-way too. Sometimes all the little details take as long or longer than the basic concept. As I was saying in my talk today, though, it’s those details that actually account for most of a system’s value. So, even though eggs are maybe 80% complete codewise, and generic functions are maybe 90-95% of where I want them to be, the missing pieces (like documentation) keep the tools from being usable by a wide audience. So, in a sense, the last 5-20% is maybe half of the system’s (potential) value.

Which raises an interesting question: is there a way for me to do that part first, and skip the other part? It’s probably worth thinking about.