If you haven't heard of Google App Engine by now, you've probably been living under a rock.  I won't try to explain it, or even include any links.  Go check out what google has to say about it: it's intriguing, at the very worst.

It's really the first step toward the distributed web as a viable application platform.

 Sure, the web's been an application platform for years now.  I ran across an article (sorry, I don't have a link to it) about a year back that  predicted 3 phases of web apps.  Phase 1 was, really, Web 2.0 (whatever that means).  You have rich applications that run on your server (or one that you rent).  Phase 2 was where we've been heading for a while:  you write "controls" that people embed in (say) their MySpace page.  Those controls call into apps that reside on your servers, and the content appears on pages hosted wherever they were added.  Phase 3 is where you get real control of apps that are truly hosted on someone else's servers ("in the cloud," if you will), using their SDK.

 Conceptually, maybe not all that different that just renting a shared host and running CGI scripts there. But it's really a huge paradigm shift.  This is the start to that.

In a lot of ways, web apps are (for what they are) at the same sort of  maturity level that PC apps were back in the DOS days. Google's doing what Microsoft did with Windows 3.1.  "See how much easier it is to develop on my platform, using my SDK, than it is when you have to worry about things like scalability, database maintenance, proprietary user authorization and authentication, etc, etc."

 In a lot of other ways, Microsoft's already done most of this with things like ASP.NET, Active Directory, etc.  And they've taken things several steps further (in the direction they want to go) with Share Point.  Those things are great, if you're part of an IT team writing "enterprise applications."  But, let's face it.  That isn't the fun stuff.  Cowboying out useful apps that people (even if they're just a few of your friends) will actually want to use...that's when software development is cool.

 So I applied for a spot as a beta tester, downloaded the SDK, and promptly started procrastinating.

 I got my notification that I had a spot in the Beta test yesterday, and I got really excited.  So I actually started messing with stuff and reading the emails I was getting from the google group.

Here are some of my initial thoughts:

 The basic SDK is nice, and you get most of the built-in python libraries.  But they "sandboxed" a lot of the functionality: you can't access the file system, open a socket, or get to low-level OS pieces.  Shouldn't be that big a deal.  But a lot of the libraries that many people take for granted also get banned from the sandbox, as a result.  Several of the libraries that I've investigated will not work as-is because of this restriction.

Python web development has changed a lot since the last time I did anything with it.  Back then, they had just published the WSGI specs (don't know what those are? They don't really matter...except the basic Appengine SDK has a lot of references to this that are really cryptic unless you're familiar with the history). Now there are more web frameworks (reminiscent of Ruby on Rails) than you can shake a stick at.

The most popular (because one of the oldest) is Django.  It really appealed to me when it first came out, but it's always felt kind of...meh.  Google has decided to support it as part of its official SDK.  So I looked into it again.

I'm still very torn.  It's much higher level than the basic appengine API calls at the root of the SDK, but it still doesn't feel right to me.  And google has gutted much of the "convenience stuff" that makes it so attractive (because of the whole sandbox thing).  I may still decide to go with it, just because it's the default.  That, and Guido was probably the one who chose it.  At least for now.

I've also looked into pylons.  Much more to  my taste.  And much more difficult to port/support.  As I understand it, there's currently a limit of 1000 files per app. If you add pylons to your app, it sucks up something like 980 of those. And I don't particularly care for what I've seen of its templating engine.  While I've been doing research, I ran across the cheetah templating engine.  I've been highly impressed by what I've seen so far.  If you do any code generation, it would probably be worth your while to take a look at this. But that would be yet another library to take precious space away from my files. (Okay, space isn't really the issue...but I prefer to have small classes, with small methods, in small files. That just seems easier to organize, to me).

Anyway, web2py claims to be working pretty much perfectly. Except that you have to use google's ORM. Which means you can't use their admin tools. But you can develop your site using their ORM and web-based admin center, then switch to using App Engine's ORM to deploy.  I'm really impressed by what I've seen of this framework so far. It seems to have taken several "best of breed" approaches from several other leadin web frameworks and mashed them together.  So I intend to take a closer look at it tonight.