Dart's biggest competitive advantage is that it has teams building compilers, VMs, libraries, apps and tools. It is not just about syntax sugar. It is also about better debugging and collaborating, improved development cycles and so on.
It seems that what you ended up doing is, in fact, reimplementing things that were implemented zillions of times before. Am I wrong or the Pump middleware doesn't work for any WSGI app? If it had followed the WSGI middleware basic concept, you'd be closer to achieve the goal of reusable components across frameworks.
"Pump aims to replace WSGI entirely." <- this is very ambitious. :)
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.
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:
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:
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. ;-)
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.
