Here’s the Deal
Slant is powered by a community that helps you make informed decisions. Tell us what you’re passionate about to get your personalized feed and help others.
While Bottle is a great framework for building small applications (generally less than 1000 lines of code), it starts getting very hard to manage your application if you want to go even a bit larger than that. The fact that it follows a single-file distribution model and that it's missing something like Flask's blueprints only make this problem worse. See More
One of Pyramid's greatest drawbacks is that it requires a lot of set up in the beginning of a project. This can feel overwhelming and can keep people away from using it. There are however scaffolds that you can use to generate your project. There are a lot of scaffolds available for any kind of project. See More
Very good tutorials and examples to help getting started fast See More
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. See More
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 See More
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. See More
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. See More
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. See More
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). See More
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. See More
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. See More
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. See More
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. See More
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. See More
Tornado is a Python web framework and asynchronous networking library, originally developed at FriendFeed. By using non-blocking network I/O, Tornado can scale to tens of thousands of open connections, making it ideal for long polling, WebSockets, and other applications that require a long-lived connection to each user. See More
The fact that a Klein server is event-driven and non-blocking means that it can start handling a new request while previous requests are still open. This lets you serve more requests from a single process, meaning running multiple servers is now an option to be explored when your site makes it big, rather than a necessity for responsiveness under even modest loads. Multiple requests per process also gives you flexibility to do things that would be impractical in WSGI-based alternatives like Flask or Bottle, such as keeping a connection to the browser open to send it chat messages or game updates in a Server Sent Event stream. See More
Talking to database is a pretty common thing for a web application to do. Larger frameworks know this, and cover it in some detail by the end of the tutorial. In contrast, the Klein documentation is currently silent on this topic, leaving the issue of how to do database queries in a way that won't block your event-driven code entirely up to you. See More
Help millions of people make better decisions.
Each month, over 2.8 million people use Slant to find the best products and share their knowledge. Pick the tags you’re passionate about to get a personalized feed and begin contributing your knowledge.