Pro Documentation is written in form of a book which is good for beginners
web2py documentation does not follow the common pattern of using Sphinx, MkDocs or ReadTheDocs which is goos for exeperienced developers. Although documentation in form of a book is very easy and good for beginners. Turning web2py the most easy and comprehensive framework to learn and also to teach.
Pro Web2py apps run on GAE, AWS, VPNs, PythonAnywhere, etc
Web2py apps are designed to be portable. With some minor restrictions web2py apps can run on any VPS on SQL databases and/or Mongo, as well as on Google App Engine with the Google Datastore. It is truly code ones and run everywhere. For example at Camio.com we use web2py internally to access a GAE datastore which contains more images than Instagram.
Pro Maintainable over time
One really positive aspect of web2py application is their maintainability over the years. Old code works even if the framework is updated to the latest version. Not only that, if code is written well it is very short and a new team can pick it up over in little time.
Pro Easy to learn without losing any power
web2py is very easy to learn for beginners, yet it has a great deal of power and flexibility as application needs become more complex. It includes an impressively comprehensive set of features, making development very productive without the need to integrate a lot of third-party libraries.
Pro No need to import the API to access the models and controllers context at every request
Models and controllers live in the context of the HTTP request. So the developer does not have to import the API to access this context at every request.
In other words, the models, controllers and templates in web2py use a domain specific language which uses pure web2py syntax and allows to import any module but exposes a few additional objects.
Pro Includes a web-based IDE for creating and managing applications
web2py includes an "admin" app that serves as a web-based IDE for web2py applications. It includes many features, such as application creation, compiling, and packaging; an error ticketing system; a code editor; a debugger; a controller doctest runner; Git and Mercurial integration; and one-click deployment to PythonAnywhere, Google App Engine, and OpenShift.
It is not intended as a full desktop IDE replacement, but it includes some helpful web2py specific functionality and can be convenient for basic editing and debugging tasks and quick prototyping, even for those who primarily work with a more full-featured desktop IDE or editor.
Con The web IDE is not a full-featured IDE
web2py includes an "admin" app that serves as a web-based IDE for web2py applications. It includes many features, such as application creation, compiling, and packaging; an error ticketing system; a code editor; a debugger; a controller doctest runner; Git and Mercurial integration; and one-click deployment to PythonAnywhere, Google App Engine, and OpenShift. However, particularly with regard to code editing and debugging and version control integration, it is not as full-featured as some of the more popular desktop IDEs such as PyCharm. So, developers expecting a PyCharm-like experience may be somewhat disappointed. In any case, use of the web-based IDE is completely optional.
Flagged Pros + Cons
Con PyDAL can be inefficient in some cases
The generated SQL does not always suit efficiency needs when performing complicated queries with JOINS. The Python code is beautiful and easy to maintain, but the generated SQL is not necessarily optimized, and the API doesn't always allow for the implementation of particular optimization tricks. However, a typical ORM is unlikely to perform any better, and any system will require tweaking and additional configuration to optimize such queries.
Of course, you can always hand code some optimized SQL and run it via the pyDAL .executesql() method, but this is a less convenient approach.
Session management in PyDAL hangs on async tasks, running on Celery for example.
Transactions are difficult to control, sometimes a lot of transactions is kept opened even using the officially proposed try: <query> except: <rollback> else: <commit> pattern (would be easy to have a context manager for that)
There are ways to optimize, but this is not out of the box
Con Integration with third party services can require extra work
Some projects needs to talk with external services that are not designed by the same developers that created the web framework.
In web apps it is very common to use things like Celery or RQ to maintain a task queue, but web2py chose to develop its own task queue and scheduling system rather than contribute to a web2py-celery integration. It is of course still possible to use Celery with web2py, but it takes a little extra effort.
On the other hand, web2py's built-in task queue and scheduling system is easier to set up and use, is documented and maintained along with the core framework itself, and is more than adequate for most typical use cases.
Finally, because of web2py's execution model, usage of some third party testing and debugging tools can require some extra setup and workarounds. However, solutions exist, and several popular Python IDE's (such as PyCharm) have built-in web2py support.
Con Data Models loading system is complicated to manage
Web2py has a folder called "models" where you can create data model files, which will be loaded (executed) in alphabetical order on every request. Although this is a convenience, especially for larger applications, a couple of difficulties can arise:
Hard to manage alphabetical order, having files like 0_first.py 2_second.py etc...
There is a way to use conditional models, but this adds some degree of complexity, requiring the creation of subfolders.
Of course, use of the /models folder is optional, and it is possible to instead define models in modules as would be typical in other web frameworks, but this approach is not discussed or promoted in the documentation.
There is also a "lazy_tables" option in the DAL, but it is not enabled by default (though it is simple to enable by specifying a single parameter).
Con Loading models on every request can cause overhead
For development convenience, files in the /models folder of an application are loaded on every request. For a large application, if all models are defined in files at the top level of the /models folder, executing all of the model files on every request can add some overhead. However, there are some simple options in place that can minimize or eliminate this overhead.
First, when defining the DAL object in the first model file, simply set lazy_tables=True. This will greatly reduce the time it takes to execute the models.
Second, by default, conditional models are enabled -- if you put model files into subfolders named for their associated controllers (and optionally functions), those files will only be executed on requests for those controllers/functions.
Finally, for larger applications with many models, the recommended practice is to put model definitions into Python modules and import them where needed. This completely eliminates any overhead associated with executing model files, as the /models folder is not used in this case.