First look: Google's high-flying cloud for Python code
Google App Engine simplifies the problem of deploying and scaling Web applications, but not without a few wrinkles and question marksFollow @peterwayner
There are other advantages that probably encouraged Google's choice of Python. The most popular implementations are open source. and the language's creator, Guido van Rossum, works there. This must have made it much simpler for the company to create the slightly crippled version of Python that runs on the app server. This sandbox forbids some potentially dangerous operations such as writing to the file system, a feature that could pretty much prevent building Flickr-like upload services unless you feel like storing these big blocks of data in the database. Your code isn't allowed to spawn subthreads, and it better be efficient because it looks like App Engine will kill any thread that takes too long. This is probably necessary given the endless loops that will be created by newbies, but it pretty much means that App Engine is really just for front ends to databases that don't do much independent thinking or computation.
Smells like SQL
It's probably best to think of the system as a thin layer of business logic in front of a simple database, the kind that DBAs like to call a "data store" to emphasize the point that you can't do most of the complicated things that Oracle allows. The database is nicely integrated with Python but it only offers the kind of basic search and store functions that developers will need to squirrel away their user's information. You set up the data objects in Python, hit the save method, and the data disappears into the cloud where all of the instances of the application can find it. The language is pretty close to SQL, but it comes with a slightly different syntax, which means that you won't be able to use any of the millions of tools that sort of speak SQL to generate reports or produce graphs. Furthermore, the data store API doesn't include old-fashioned joins, an omission that will break some of the code written for traditional databases. The simplicity is nice, but there's a reason why everyone ends up using standard databases for the core of their projects.
So there is a certain amount of lock-in hiding in the API. Porting your application to something like MySQL won't be automatic but I doubt it would be hard at all. Going in the other direction, though, could be both healthy and annoying. Because there's no way to join tables, you're effectively forced to denormalize your tables. Most Web developers end up doing this eventually to help things scale, so I guess it makes sense to start out that way even if it seems a bit messy.
Nor are there many of the tools that might be essential. The samples and the tools all run through the command line, probably the preference of the developing team. I can see that developers might want more sophisticated tools for profiling the code and tracking every click. Google suggests profiling by dumping the profile information between <pre> tags in an HTML document. Using <table> tags would probably confuse the command line jockeys.