web2py -> Django -> Turbo Gears -> Pylons -> Web.py
On the left you have more fully integrated frameworks that do more out of the box (and essentially make more choices for you upfront). On the right you have frameworks where you do most of the work yourself. These frameworks eliminate some of the boiler plate of writing a web applications and give you the responsibility of handling the rest.
Which one to use depends on what you're looking for.
There is no reason any of the above frameworks can't handle a "digg effect". Just throw servers at it.
The reason I chose it was because it sits in the middle. It does a lot of stuff for you... but you can get rid of most of it when you need to.
Looking at web.py I think you'll suffer from the poor docs and the code can get a little hairy.
As a simple web server you may want to check cherrypy (which under pins TurboGears). It's got a good reputation, good docs and can be deployed in a variety of ways behind apache (or many other web servers)
Anyway, I agree with Cosmin's assessment that it grew to do a lot more. The main phylosophy is that the framework should make (by default) some decisions for the user, in particular particular about things that have to do with security and persistance.
At high level web2py borrowed some ideas from Django (the administrative interface and {{...}} in templates), some from Turbogears (response.flash?) and some from cherrypy (@cache).
I suggest going with Django. There is a little more upfront learning, but it's worth it.
I wouldn't worry about the digg effect. Worry about making something good -- which means making anything as fast as possible and asking people what they really want.
If you are running web.py as a fcgi process, you'll handle a digg effect just fine.
If not, you'll peg the server and your site will be largely unavailable.
Happily, switching web.py from fcgi to non-fcgi mode or back again is a single-line change :)