Wednesday, August 06, 2008

Duck Typing Sucks.

I'm working with some code that's written in Python, and makes extensive use of duck typing. In duck typing the premise is that if it quacks like a duck, it is a duck.

Of course, if you've got code that doesn't tell you what it expects to receive, you can't hope to figure out what the type should be.

For example, let's say you've got 3 code blocks:

class A:
    def funkyDuck():
        # random cool stuff

class B:
    def funkyDuck():
        # entirely different cool stuff

class C:
    def funkyDuck():
        # a third entirely cool thing

Now, imagine you're looking at code that goes:
some_random_object.funkyDuck()
Which one gets called? By the way, they're all in different files, so the only way to find them is with "grep". Added bonus, the undocumented hash!
    def addApplications(self, appDict):
        """ Add some application modules to the defaults.
            All binaries and libraries in any of the source dirs will be soft linked
            to a directory with the name of the product.
            @type  appDict: dict of string -> (list, string)
            @param appDict: The source dirs and OS user name for each product
        """

Guess I'm supposed to guess what appDict actually looks like.

Hrm. Perhaps my problem isn't with duck typing itself, but it's use here.

Hint: When your test framework is just as complicated as the program under test, you're doing something very, very wrong.

4 comments:

Tony Garnock-Jones said...

It puzzles me that python doesn't yet have an IDE (by which I mean something roughly Smalltalk-80-equivalent, with a good browser, a debugger, an object explorer, an interactive workspace, a profiler, a type analyser etc). Having an IDE could have helped you here in that real IDEs can do better than grep.

The appDict thing is evil, though. (Although actually, even here, a real IDE would help, in that you could use the object explorer to examine a real appDict at runtime.)

Jason Pollock said...

That would remove a lot of the pain. :)

I personal solution was to pass the problem back to the developer who wrote it and get them to make my changes. ;)

Leo said...

Program to an interface, not an implementation!

And now, for something completely different...

Jason Pollock said...

In order to figure out which one is broken and _fix_ it, I need to be able to find the implementation.

Duck typing makes it hard to figure out which piece of code is going to be executed because it is so context sensitive.