The app-engine-patch team has essentially forked Django and made it work on top of GAE models. However, there are some disadvantages, including a huge perf hit on cold requests. I tend to avoid AEP.
I'm currently of the opinion that trying to get "all of Django" running on GAE is square-peg/round-hole. You still get a lot of mileage from the bits of Django you _can_ use on GAE, and it's modular enough that it is possible to build new GAE-specific session, etc. objects. I have several OSS repositories on GitHub that could serve as a decent Django + GAE template if you're interested.
My current focus is to look at the plethora of excellent SaaS applications that help provide the whole Rails ecosystem, then turn around and do the same for Django, with an eye towards expanding to handle other Python frameworks, and then into the Java space.
Going down to the metal may help squeeze the last 10-20% out of your hardware, but the the really interesting and challenging work in coming up with a scalable hosting platform is elsewhere: security, monitoring, process spawning/reaping, deployment, et. al. If working in Python gives you a time-to-market advantage, then go for it. You can hire a C hacker when you have enough business to make the improvement in your hardware utilization efficiency pay off.
Other than that? Lots and lots of python, of course ;) I'm only one guy, and there are three or four big moving parts that need to be written. Something to build eggs and push them, something to monitor and manage processes on individual servers, something to dispatch requests to the appropriate servers, and something to monitor and manage the database servers.
Even pulling back and looking at a minimum viable product, I'm still doing most of that work, just far simpler versions. Succinctly, it's too big for me to tackle on my own in the next six months.
It did deploy on commit/push, bundled eggs, worked with mysql or sqlite and redis. Dunno if that sounds interesting to others though.
Basically, nginx fronts a bunch of Varnish caches, which are then in front of a "routing mesh", which queues up requests for individual "dynos". A dyno is a single-threaded instance of your application. When one dies or is migrated, another is deployed in its place. Multiple dynos are automatically spread across multiple machines. It's a very neat solution to automatically scaling hundreds or thousands of apps.
In other words, bundling the apps and pushing them out is just the beginning of a pretty fascinating architecture.
Talking to some other Pythonistas, there didn't seem to be much desire for a Heroku-equivalent system though - most ppl enjoy rolling their own deployments.