Blub paradox

In my last post, I mentioned some of the pitfalls I personally ran into when I started working with App Engine. Being a python newbie didn't really help either ;-) The one thing however I probably should have stressed a little more in all of this is: it gets better over time. As I keep working on python based projects, familiarity and coding speed increase. Having a great community of developers available on forums doesn't hurt either, plus the App Engine team continuously keeps cranking out great usability improvements (just look at the recently released SDK 1.1.9 and you know what I mean). Not only that -- they actually listen to the community and do whatever they can to identify and address common pain points. It is fun to use a platform that is well supported, has a huge fan base and still keeps getting better! Having said that, I need to find something else to complement my App Engine skills, and here is why:

While all these upcoming new and exciting features are really nice, I would like to take a step back today and focus a bit more on one of the basic issues that a developer may run into when switching languages and frameworks: the Blub paradox. Blub, a fictive language discussed in a classic Paul Graham essay, represents a language XYZ that a programmer is used to work in. For me, this has been Java in the past, but it could be pretty much anything else. The Blub paradox states that programmers are "satisfied with whatever language they happen to use, because it dictates the way they think about programs." As a corollary, when having to work in a different language, programmers tend to mentally code in what worked best in "Blub" instead of what works best in the new language. It's like trying to speak Spanish by translating English sentences word by word: something will come out of it, but it is not really ideal.

I recently ran into the paradox myself when I gave bad advice to a fellow developer who pinged me with a question:

Which would you say would be preferred way of implementing the following.

I want to instantiate a subclass of db.Model from a dictionary of values, and I also want to make sure that an instance has valid values for a subset of required fields before saving the object. Should I:

1) Have an __init__ method on the subclass that accepts a dictionary (assuming that is allowed) and have the property fields declared as required=true and set the values from the dictionary in the constructor, or

2) As is usually true for Java for persistent classes, allow for zero-argument constructors, and implement a static create() method on the class to create the object from the dictionary and a static add() method on the db.model subclass that checks for required fields before saving the instance via a put(), or

3) Something completely different, perhaps involving the validation capabilities of properties.

The question (and especially approach number 2) pretty much demonstrates the early stages of switching frameworks: I have problem XYZ and a couple of approaches how to solve this in a language A, but I need to use language B for this project. How do I translate the code?

I have to admit that my initial response to the question was not particularly bright: rather than questioning the rational behind it, I simply responded with a slight tweak to the code translation:

I would probably go with an __init__ method with an optional parameter, something like

def __init__(self, from_dict={})
  for key, value in from_dict.items():
    setattr(self, key, value)

While this looked like it should work, the devil turned out to be in the details. A few hours later, I got another mail:

This turned out to be much trickier than I thought, especially for a beginning Python programmer.

What ended up working was:

    def __init__(self, plistDict=None, **kwargs):
        if plistDict != None:
            for key, value in plistDict.items():
                kwargs[key] = value

        db.Model.__init__(self, **kwargs)

What made this so tricky was that the implementation of db.Model.__init__ REQUIRES that the values of any properties be in kwargs.

Just thought I'd pass that on.

At this point in time, it hit me like a ton of bricks: I had fallen into the trap! The App Engine team contains some of the brightest minds in the python world -- they would never build a framework that makes such a simple task so hard!

After a little extra research I realized that in order to make his use case work, my fellow programmer actually needed exactly zero lines of customization: support for dictionaries was already baked into the standard Model constructor:


someInstance = SomeDbModelSubclass(**myDictionary)


The double asterisks, as described in the Python documentation allows me to inject arbitrary key/value pairs as arguments into the constructor. To be precise, here is the quote from the documentation:

A function call always assigns values to all parameters mentioned in the parameter list, either from position arguments, from keyword arguments, or from default values. If the form "*identifier" is present, it is initialized to a tuple receiving any excess positional parameters, defaulting to the empty tuple. If the form "**identifier" is present, it is initialized to a new dictionary receiving any excess keyword arguments, defaulting to a new empty dictionary.

If we construct a Model instance in App Engine like

MyModel(prop_1=13, prop_2='hello world')

then the Model constructor actually uses this very same mechanism to populate properties. It is a standard feature of the python language, beautifully utilized in App Engine's API -- and completely novel to anyone who has only done Java code before! I just got hit by the blub paradox!

Having run into this made me wonder: how much unnecessary code do I have in my other python-based programs? Have I reinvented the wheel? I have decided that it does not matter too much, as long as my code works and I learn from my mistakes. It does show me however that I should keep learning new languages or frameworks on a regular basis. By getting introduced to new concepts I can broaden my perspective and produce cleaner and better code. By just doing "what I've always done", I will stagnate and become a less effective programmer.

So, what should the next thing be? I currently tend towards GWT, because I think it is really cool and fits well into the program-web-apps-with-App-Engine theme. I'm open towards recommendations though. Pleast post comments.