The most often mentioned is Django.

We picked Tornado (tornadoweb.org) because it is lightweight and fast, especially on cold start, which is an app engine issue for low-traffic apps. It's even faster than webapp (!) because webapp loads the Django templating system.

We've been happy with Tornado, although it doesn't have as much support for some stuff (e.g., web forms). It does have a templating language which is just embedded python. I like having the power to have a reasonable "if" statement or "for" loop, even though most people believe that embedding complex logic in templates will produce spaghetti.

See also http://stackoverflow.com/questions/70913/which-python-framew... and http://www.quora.com/What-is-the-best-Python-Web-Framework-t...

The real answer is "anything but Django." Django is a great framework, but not for GAE.

I've used tipfy.org

Why is Django(-nonrel) a poor choice for GAE?

You said it yourself. The Django ORM is designed for relational databases. Django-nonrel seems to work, but it's a second-class citizen in the Django world. Much of the appeal of Django resides in the ecosystem of pluggable apps, and most of them won't work or will fail subtly when running on GAE.

Okay, fair point about the third party apps. But even without them, it's not obvious to me that writing a Django-nonrel app from scratch is the worst option available.

Django is a full-stack framework with a monolithic approach. The fact that it is possible to switch some of the components doesn't really mean that it is advisable to do so.

I've worked with Django for 3 years, and in my opinion Django actually has a non-negligible learning curve. If you have to give up the benefits of the full-stack approach and of the Django ecosystem of pluggable apps, you might as well go with something simpler, such as Bottle or Flask, or choose a full-stack framework that officially supports GAE, such as web2py.

I've tried django-nonrel as well - if you're not trying to get an existing django app running on app engine, I'd stay away from it. In practical experience, we saw our handlers taking 3-5 times longer when using Django-nonrel.

Tornado is great as a standalone API/WWW server, but for WSGI-based environments, like Google App Engine, I would choose Flask (>= 0.7.1) over any other framework.

Flask, despite being a micro-framework, is extremely powerful. It's core is well-written and there's a lot of useful extensions out there (like Flask-WTF or Flask-Assets). Flask also works really well with Google App Engine (see example skeleton: https://github.com/kamalgill/flask-appengine-template; there's more on GitHub). With little effort you get WTForms and even Webassets support almost out of the box, in really elegant way.

Tornado will also do, since it's very similar to webapp and has very good templating system. However, since extensions ecosystem for Tornado is almost non-existent, one has to write more code to make up for it (e.g. integration with Webassets, management commands, OAuth support etc.).

There's also Tipfy, but I have absolutely no experience with it, so I can't vouch for it.

I have used Tipfy for a couple of projects. It is VERY lightweight and flexible, and comes with jinja2 templating built in. Basically webapp + some missing components, like Session management. It's not even as close to as robust as Django-nonrel for GAE but depending on the scope of your project it might be perfect

Flask.

Docs: http://flask.pocoo.org/

Seconded. We used the flask-appengine-template (https://github.com/kamalgill/flask-appengine-template) and it's been great so far.

Flask and Jinja2 make views and templates really easy, and the AppEngine data store fits well for the models.

I will third and fourth Flask for App Engine. For me, it strikes exactly the right balance between light-weight, flexible, and powerful.

+1 for Flask here. The documentation especially is on another level. A lot of commitment here with an active developer community.

Agreed. I'm more of a Rails/Sinatra guy but if I had to write something for app engine I'd definitely start with Flask.

A nice alternative to the built-in webapp framework is webapp2: http://code.google.com/p/webapp-improved/

It's basically a superset of webapp with some great additions and tweaks.

Thanks for the mention! (I'm the webapp2 author).

A big advantage of webapp2 is that you can use existing (and probably future) SDK libraries without adaptation. Many App Engine services (blobstore, mail handler, deferred etc) use handlers made for webapp. With webapp2 you get all those handlers working out of the box with extra benefits: webapp2 is a lot easier to extend and includes the most glaring webapp missing features.

Also, you can use all the examples from the App Engine documentation with it, since it is made to be compatible with webapp. And later you learn the new, extended features.

I'll second this suggestion. In my experience so far, webapp2 is a great way to get beyond some of the stranger idiosyncrasies of the default webapp without being overwhelmed or completely throwing away the benefits of Google's extensive documentation. If you like an extension or modified feature, use it. If not, do the way Google tells you to and it'll work just fine.

If you use nothing else, the extended routing functionality and lazy loading of handlers are big improvements and are pretty painless to implement.

I like Bottle: http://bottlepy.org/docs/dev/

I've used bottle for many projects and I'm very happy with it. A new version was just released a few days ago as well.

One thing that I love about bottle is that it is one of the few web frameworks that supports Python 3 (as does CherryPy, I'm told). Not that it matters one bit if you're running on GAE, which only supports Python 2.5.

one nice thing about the web2py Data Abstraction Layer is that it doesn't have any dependencies. It's just a single file, and it seems to be pretty easy to use with Bottle, which doesn't have any data abstraction layer:

http://martin.tecnodoc.com.ar/default/post/2011/05/25/21_bot...

None. Just use webapp and you'll be happier, and faster.

Btw, we use webapp with some sugar on top to make it sweeter:

    import app

    class Index(app.request):
      def get(self):
        self.show('index')

    app.run('/',Index)

No framework in the whole world can make coding in AppEngine that easy.

At both http://albumpl.us and http://jaavuu.com we use webapp plus pytenjin: http://www.kuwata-lab.com/tenjin/pytenjin-users-guide.html

In addition, we have a small home-grown framework ("glue") that holds it together, but it's probably only about 100-200 lines of code. The advantage is that we know it and can maintain/add features easily.

But then again we don't really need a low end CMS, which is what many of these other frameworks try to provide.

We use django, but yes, google only officially support webapp and you may end up having to translate docs from appengine entities to django objects.

I've used web2py on GAE and it's working nicely, with most of the GAE quirks taken into account out of the box. Everything has been taken care of as far as making your app work with GAE is concerned. The site I'm running with web2py + GAE is:

http://www.cvstash.com

The web2py author also admitted a few months back in the mailing list that google was paying him to test out the framework against GAE. So I think that means the GAE support would be production-ready at the very least.

For reasons that escape me, web2py doesn't seem to get much love, but deploying a web2py app to GAE takes all of 5 minutes. Web2py uses a DAL instead of an ORM, which means it's much easier to use the same data model on the non-relational datastore.

(The inevitable restrictions imposed by BigTable still apply, see http://www.web2py.com/AlterEgo/default/show/138).

Does the web2py database abstraction layer support datastore transactions and query cursors? Or what datastore features it doesn't support?

(apparently the documentation doesn't mention any datastore feature it doesn't support but the last time I checked it did not support at least transactions)

I don't know, I haven't had to do transactions. Another advantage of the web2py DAL is that it doesn't have any dependencies. It's just a single file which could be used by any other web framework to decouple from BigTable and enhance portability. An Argentinian developer shows how easy it is to use the web2py DAL with Bottle:

http://martin.tecnodoc.com.ar/default/post/2011/05/25/21_bot...

It should be added to the documentation which datastore features it doesn't support, to warn users and avoid that the GAE support is misinterpreted as bad advertisement.

You can use the GAE datastore transaction with the web2py DAL but it does not provide an API with it, you have to use the GAE function for the transaction and than inside you can use DAL syntax. DAL automatically creates one cursor for you per http request. Each request has its own. It does not provide APIs to make your own cursors.

I think you're confusing the general idea of cursors with datastore cursors, which require a query and can't be created "per request", but "per query". See:

http://code.google.com/appengine/docs/java/datastore/queries...

Sorry I misunderstood. Web2py has not API for it but it should be easy to add. If you open a ticket on google code, it will done sooner than later. ;-)

Some have suggested it is because it originated from academia and not from industry. Tools originating from industry people assume they have already proven their values while tools originating from academia need to prove it.

I have the impression that experienced Python programmers don't feel comfortable with web2py's controversial (some would call "unpythonic") approaches, like automatic imports or the use or exec.

There are lots of popular python tools that do something very similar to web2py. For example visit, enthought, blender, pygame. "exec" is the only function that distinguish a purely interpreted language forma a compiled one and it is a powerful tool. I agree there are improper uses for exec but that is not the case of web2py. Web2py does have "automatic imports"; web2py exec(s) code in an predefined environment and that is the proper way to use exec. Those who criticize web2py for for this either do not undertand why we do it or are being partisan. I will agree that every design choice has pros and cons.

I haven't yet used it on GAE, but web2py is awesome, and works on everything including Jython, CPython, GAE, any database you can throw at it. It is sane, quite easy to use and reasonably fast.

web2py is underestimated IMO - give it a try.

It's going to be hard to get the 'best' framework, but you'll certainly get a lot of responses of frameworks that definitely work for people. I'll add:

Tornado

http://www.tornadoweb.org

Web2py has some GAE-specific features to ease installation and operation.

Tipfy

Tipfy is nice, but its documentation is horribly out-of-date. The last time I tried using it, I had to dive into the source code several times to figure out what was going on. Eventually I ended up moving off of app engine. (I considered contributing to the docs, but I would have had to spend a lot of time learning the codebase as parts of it had been heavily restructured since the docs were last updated.)

Agreed. Tipy is awesome! http://www.tipfy.org/

Yes, but the documentation is a little out of date as the current version has changed significantly. Basically, don't go by anything you find on the web, make sure you use the docs/examples in the mercurial tree

Webapp2: http://webapp-improved.appspot.com/