Jonathan wrote his thoughts about App Engine . They are well worth a read if you are thinking about using it, but haven’t so far. I used App Engine sporadically for a couple of months on a project of mine, but I finally gave up and ended porting my code to pure Django , which admittedly wasn’t too hard to do at this point in time.

Some of my reasons match Jonathan’s. There were too many rough edges to feel really productive and too much time was wasted on trying to find out if problem lies in poor documentation, incomplete implementation or stupid programmer. I probably will never get answers to questions like how can a simple Django view that doesn’t do anything beside rendering a static template, consume above expected amount of CPU and risk triggering quota blockage, but right now I really don’t care anymore.

Integrating Google accounts is indeed easy, but it is also very shallow to the point of being practically useless.  You basically can only rely on fact that reference to a particular user won’t change. Anything else you may think you know (like an email address), can’t be relied upon. You can’t create an account and you can’t even control login form of your service. In essence you don’t have your own users, you can just offer a service to Google’s.

For me this was one of two major reasons for my decision. Every person who would need an account to use what I am building would need to agree to Google’s TOS agreement which defines many things, among others the highest level of privacy I can offer.

The other reason was that current limitations of App Engine really lead you to rely heavily on provided APIs, which may be similar to stuff out there (like Django), but aren’t anywhere close to being a drop-in replacement. This can be — depending on application you’re writing — a heavy investement in a platform you don’t control a bit.

Put more profanely, you are a Google’s bitch.

Having said all this, I do think App Engine is a very valuable service. If you want to write a mini-app, a web tool like Simon does , then App Engine is brilliant. You can do this easily with little deployment and zero administration hassle. In fact I can’t think of any other service better suited to this task.

I’m sure this is not the only scenario in which App Engine makes sense and there are others I haven’t named or thought of. Issues, like accounts, can with some effort be solved now. But App Engine also isn’t (yet) what some of us were hoping for and it’s prudent to really think through what you want, what you need and what App Engine actually offers.

Fry published few neat Greasemonkey scripts recently and since I am also a fan of this Firefox extension , I thought I might share one myself. It’s a script I am using right now, while I am typing this post.

Script hides everything but editor on “Create New Post” page in WordPress . It also adds a toggle to the right which you can use to control visibility of hidden parts.

I did this because I don’t want to be distracted when I am writing and close-to-empty page helps me stay focused. If you’re like me, then please download the script.

It’s been a while since I used Python for anything larger than scripts few tens lines long, so it feels really great to do it again. I did discover however that I became a bit rusty. Not so much in not being able to achieve what I want as not being sure that I do it in a sensible and pythonic way.

I’ve been working on a private project where I came to a following problem. API calls can trigger various responses, somewhat like HTTP , containing status codes together with a short description. Every faulty response should trigger its own exception, which led me to my first implementation:

class Unauthorized(Exception):
    status = 101
    value = "Unauthorized."

I didn’t like it even though it looks and behaves like it should. What I wanted was a better overlook of possible responses in a way where I have to make any possible changes easily and only at one place.

My second attempt was auto-generating exception classes using type. Since class definition took only a line instead of three, it certainly achieved better transparency, but I still had to make changes at two places.

Final step was to auto-generate classes in a loop. To do this I attached them to module namespace using globals() dictionary. Actually I used __builtin__ one at first, but it obviously didn’t work that great.

So this is what I have now. It works and achieves my goals. I only need to change dictionary to add a new response or change existing one and it could hardly be more readable.

But is it pythonic enough? If not, what would be, apart from traditional way described in first step?