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.
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:
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. ;-)
My advice is take 5 minutes with both (Django and web2py). Even if you choose Django, web2py has a web based IDE which will teach you the MVC design (which Django calls MTV).
web2y also takes much less time to get up and running therefore it is no really extra cost to try.
Most concepts translate line by line (Django admin ~ web2py appadmin, Django request.POST ~ web2py request.post_vars, Django request.GET ~ web2py request.get_vars).
The latest web2py also use a thread local object (a cool stolen from Flask). web2py has a pure Python template language, Django has a domain specific language for templates that is not Turing complete. In Django you have to explicit about everything (for example you have to list all mapping of URLs into function calls) while web2py has defaults and conventions (which can be overwritten) and it feels closer to ruby on rails.
Web2py comes with more stuff in the box (more supported databases, runs on Google App Engine including db queries, credit card payment api, multi-tenancy, multiple types of federated authentication, pdf generation, hooks for nginx/gunicorn/gevent, etc).
Web2py does not mess with python internals and has more readable code than Django, for example it does not uses complex meta-class programming for the ORM. What some do not like (but buys you a loot of goodies) is that web2py executes some of your code instead of importing it. This allows hot plug and play of applications (even in production) and allows to run multiple apps under one server without library conflicts.
web2py is very secure. For example it had cross-site-request-forgery prevention 2 years before Django did, despite being at least 4 years younger.
Both can be used exclusively from the shell. web2py can also be used from the web based ide but does not force it on you.
