Wednesday, August 24, 2005

Code Jam 2005

I tried my hand against around 5000 other programmers in Google's Code Jam 2005. Last year Windows corrupted the hell out of itself halfway through, when I had foolishly not saved any work. The time and concentration lost rebooting killed me. (I had the infamous anti-aliasing problem for my 500pt question. The lowest qualifying score from that group was in the 170s, IIRC. Google dialed down the difficulty considerably this year.)

This year I went into battle armed with Visual Studio 2005. TopCoder doesn't recognize any of the beta additions, but Studio 2005 has a pretty decent Emacs mode. Instant 10% productivity bonus!

The alert reader will have already noted the use of the past tense in the first sentence and concluded that I didn't make it into the top 500 to qualify for the next round. Correct; I missed the cut by 4 points (732 to the 100th place guy's 736).

Ouch. I'd kinda rather have been way outclassed than lose by 4 points out of 1000. Now I'm kicking myself for wasting time checking and re-checking that I hadn't missed something in the 750 pt problem before submitting. It was just so much easier than last year's 500 pt question that I thought I couldn't have solved it that quickly. Having to shake the rust off my C# (what do you mean, you have to declare types? That is so last century!) didn't help either.

Maybe next year they will have Python and the top spots won't be so completely dominated by C++ people with dozens of topcoder-specific macros. Grr.

Wednesday, August 17, 2005

Durus 3.0 alpha released

Thought this was worth pointing out since the Durus guys don't seem to make PR much of a priority. (No slur intended. You could say the same thing about Spyce. :)

Durus is a python object database similar to ZODB, but (much) simpler. Their Pycon 2005 paper is a good intro.

Here's the 3.0 changelog. IMO the coolest parts are zlib compression and incremental packing.

Spyce has a Durus interface (spyDurus) that makes persistence even simpler than the various ORM tools. The to-do demo uses Durus.

Sunday, August 14, 2005

A little PHP humor

(Seen in a slashdot comment.)

Possible mottos for the PHP project:

PHP: We'll be there for you if your development environment doesn't have enough side effects.

PHP: Because we know the money's in the maintenance contracts.

PHP: Because you obviously don't know any better.

PHP: We take security as seriously as Microsoft ten years ago.

PHP: Doing it fast is always better than doing it right.

PHP: Proving that if any idiot can write an e-commerce package, any idiot will.

PHP: Yet another great reason to make regular backups.

PHP: Fast, cheap, and robust. Two out of three ain't bad, right?

Sunday, August 07, 2005

Guido's OSCON Python keynote

Guido has posted his powerpoint slides in the usual location. (Opens fine in OpenOffice.) The slides are mostly the same as the ones from EuroPython a month ago; here are the main differences:

  • Some odd slides during the introduction (anyone who was there care to explain these?)
  • language data scraped from -- or you could just look at this page; no need to scrape and piss off SF for something this simple. (Poor Dylan -- even less projects than Cobol -- 2 vs 4.)
  • "What does this buy us" slides added to 342 (generator) and 343 (with) PEP discussion (highly recommended if you haven't been following python-dev religiously)
  • Exception reform discussion

Personally, the "with" statement excites me the most. The exception cleanup is overdue but less sexy. :)

The static typing subject has been talked to death but I'll add my two cents.

Basically, it's a bad idea because it kills duck typing by requiring interfaces like "iterable"--a horrible idea even if all stdlib classes grow corresponding interfaces. The repeated realizations that I can't use a library because its author didn't bother making interfaces for the basic classes involved is a large reason I don't feel comfortable in static languages anymore.

"Adaptation" solves that problem in theory; in practice, having to create adapters to convince Python to treat my objects as ducks would be a noxious imposition. Code that exists only to convince the runtime that I know what I'm doing is un-Pythonic.

On the other hand, I think it would be misleading for "x: file" to not perform any assertions at all, and therefore also a bad idea. Better than inflicting interfacitis on Python, though.

Friday, August 05, 2005

Open-source, subversion, mono, and gcc

I read a blog entry about a subject dear to my heart: migrating from cvs to svn. I know svn isn't perfect, but it's just so much better than cvs that it's no contest. If you have objections to svn that are even just a few months old, they have probably already been fixed. One of the first things I did at my new job was to perform the migration and everyone (well... all one other developer who was hired before I was and is still there) thinks it was a great move.

But I digress. Sort of.

Reading said blog, I thought, "Ha, cool! Those Mono guys whined about svn blame being slow, but then those manly GCC guys dug in and fixed the problem instead of whining some more!" What a poster-perfect picture for the virtues of open-source, huh?

Except, while looking for more details, it turns out that the developer responsible for the fix, Daniel Berlin, was a svn developer from way back. As well as (possibly more recently) gcc. (Does this guy ever sleep?)

So it's a little less heroic than it initially appeared, but still, not something you'd see in the closed-source world. "Hey, Microsoft: that bug in Excel, the one you weren't going to get to for a while? My buddy used to work on the Excel team. Mind letting him fix it for me?" Right.

If anyone knows a more complete/accurate summary of what happened here, my curiosity is piqued. The best I could find is from early in the process and not very detailed.


Here's a piece of code for the one or two other developers writing intensely network-dependent code in Python. The idea is, instead of a protocol that looks like


You save overhead (in your protocol and in the network's, if you're doing one connection per command) by batching things:


Pretty obvious stuff, no doubt. But I thought the following class makes it rather elegant.

class NagleQueue:
    When an item is put, NagleQueue waits for other puts for
    aggregate_time seconds (may be fractional) and then calls
    aggregate() with a list whose maximum length is max_items.

    TODO: currently, NagleQueue always waits the entire aggregate_time,
    even if max_items items are added sooner.

    NagleQueue starts a thread to handle the aggregate() call;
    this is not a Daemon thread, so you must call stop() before your
    application exits.  NagleQueue will process any remaining items,
    then quit.

    It is an unchecked error to put additional items after calling stop().
    (They may or may not get processed.)
    def __init__(self, aggregate_time, max_items):
        self.q = queue.Queue()
        self.running = True
        self.aggregate_time = aggregate_time
        self.max_items = max_items
        threading.Thread(target=self._process, name='naglequeue').start()

    def put(self, item):

    def stop(self):
        self.running = False

    def _process(self):
        while True:
                item = self.q.get(timeout=1)
            except queue.Empty:
                if not self.running:

            L = []
            while True:
                if len(L) >= self.max_items:
                    item = self.q.get_nowait()
                except queue.Empty:

    def aggregate(self, items):
        combines list of items into a single request
        raise 'must implement aggregate method'

Wednesday, August 03, 2005

Python at the .NET user group

I was invited to present on Python and IronPython at the Northern Utah .NET User Group last night. I spent the majority of the time on Python itself, guessing (correctly, with the exception of a couple Zope users) that most people wouldn't know anything about Python beyond having heard of it.

There was a lot of participation. It ended up lasting about 90 minutes, with a lot of Q&A throughout. I enjoyed myself and I think most of the .NET guys did too.

Thanks for the chance to speak! A PDF of my slides is up here.