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.
Django was first released in 2005, it has had a lot of time to mature and become better with each release. It also has by far the largest community out of all python frameworks who have continuously over the years built and maintained many powerful plugins. See More
Given a GET request for /topics/426/viewpoints/1/sections/create, how does Django decide which bit of Python code is invoked to handle it? It compares the request path to your giant pile of regular expressions. And then if there's some other regular expression starts matching /top and all your requests for /topics/ start going there, good luck figuring out why. You won't be informed of any conflict until you notice you seem to be getting the wrong pages back. The structure of URL paths is almost universally hierarchal. There is no call to have anything as ridiculously flexible (and notoriously hard-to-read) as regular expressions to organize request routing. See More
If you make a typo in a template variable, or change a view so that variable is no longer passed to the template, you won't get an error message pointing out that something has gone wrong. That reference will just be treated as if it is an empty string instead. There is a way to configure this, but since so many templates have been written assuming this behavior, nobody ever enables template errors because it would break so much of the existing support tools (e.g. the built-in admin interface). See More
Django supports Object-Relational Mapping. With models defined as Python classes which are actually subclasses of Django's django.db.models.Model. Each attribute of the model is then represented as a database field. Queries are lazily executed and Django gives developers an automatically-generated database-access API. See More
The official Django documentation is probably some of the best around. Well written, thorough and they explain every little detail of the framework. Django is also a very popular tool, with an extensive community and a lot of experienced developers that have been using it for years. This means that there are a lot of guides and tutorials out there for new and experienced developers alike. See More
Just a few lines of code can instruct Django to create all the tables and fields required in your database automatically. Schemas are managed with "migrations", that are also created automatically, and can be rolled out from your development box and implemented on production systems with just a single command. This performs any database changes required, from table creation, indexes, renaming fields, and pre-populating initial data. Each migration builds on the previous migrations, so you can trace the evolution of your data and even recreate the layout of your database at any point in the lifecycle of your application. See More
Often you are not even aware of all the steps that the framework does in the background (a good example is Rails). Flask is very much straight-forward about what processes take place, so when you learn it, you become very proficient and don't lose any skill even when changes or updates are implemented that disrupt the usual workflow. See More
If you are not heavily into programming and don't want to think about how stuff works in detail, learning how to use Flask can be too much. You would probably be better off using frameworks that hide most of the nitty-gritty details from you. See More
Even though it's pretty minimalistic out of the box, Flask still provides the necessary tools to build a quick prototype for a web app right after a fresh install. With all the main components pretty much packed in the flask package, building a simple web app in a single Python file is as easy as it gets. 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
Some of web2py's design decisions are considered unorthodox in the Python web framework world, particularly the decision to execute application models, controllers, and views in a prepared environment that already contains many of the core API objects (such as request, response, session, HTML helpers, and form validators). Although web2py has made these decisions for a reason in order to facilitate greater productivity and ease of use, they can sometimes lead to some confusion for developers used to doing things differently. 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
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 plugin system consists in a set of files to be unzipped/extracted inside the application folder in the same way common applications are done but having "plugin_" prefix to files. You create a structure of files like modes/plugin_something.py - views/plugin_something/index.html - controllers/plugin_something/index.py The process of installing a plugin is unpacking those files in web2py/applications/yourapp folder If sticking to the "plugin_" naming convention, the system is not so flexible, and if you have lots of plugins, it can become somewhat cumbersome to maintain. Because there are no standard configuration or environment variables defined in each app (for example, pointing to the application's primary database), it is a little more difficult to develop generic plugins, as the plugin must be designed to allow the user to do some configuration in order to specify details of the environment. Also, although it is a relatively simple operation to download and unzip a plugin, it would be easier and promote better automation if plugins could be distributed and installed via pip and then registered with a web2py application. 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
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 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
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
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
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.