Get an in-depth understanding of several commonly used Python Web frameworks

Among various language platforms, Python probably has the most web frameworks emerging. It is a world where a hundred flowers bloom, with countless micro-frameworks and frameworks. The reason may be that it is very simple to construct a framework in Python, making The wheel keeps being invented. So

There are always topics in the Python community about which Python framework is better or worse. Let me introduce you to several major python frameworks:

Django

Django should be the most famous py framework, Google App Engine and even Erlang have frameworks that support it Influence.

Django is taking a large and comprehensive direction. It is most famous for its fully automated management backend: you only need to use ORM and make simple object definitions, and it can automatically generate database structures and full functions. management background.

The convenience provided by Django also means that Django’s built-in ORM is highly coupled with other modules in the framework.

The application must use Django's built-in ORM, otherwise it will not be able to enjoy the various ORM-based conveniences provided in the framework; in theory, you can switch out its ORM module, but this is equivalent to renovating the completed If the house is to be demolished and renovated, it is better to go to the rough house to do

brand new decoration from the beginning.

Django’s selling point is its ultra-high development efficiency, but its performance expansion is limited; projects using Django need to be refactored after the traffic reaches a certain scale to meet performance requirements.

The shortcomings of Django mainly stem from Django’s insistence on making all the wheels by itself. The entire system is relatively closed. The most criticized aspects of Django are:

· The system is tightly coupled. If you think Django has built-in A certain function of it is not very good, and it is difficult to replace it with your favorite third-party library, such as the ORM and Template that will be mentioned below. It is almost impossible to use SQLAlchemy or Mako in Django, and even with some patches, it will make you feel very, very awkward.

· The ORM that comes with Django is far less powerful than SQLAlchemy. Except for Django, SQLAlchemy is the de facto ORM standard in the Python world. Other frameworks support SQLAlchemy, but Django still insists on it. My own set. Django's

developers also discussed and tried to support SQLAlchemy, but finally gave up. It is estimated that the cost is too high and it is difficult to integrate with other Django modules.

· The Template function is relatively weak and cannot be inserted into Python code. To write more complex logic, you need to use Python to implement Tag or Filter. The design of Django's template system is very interesting, and it should be the most influential and controversial part of its framework.

The design philosophy of Django templates is to completely separate code and styles; asp.net advocates the separation of code/templates, but technically they can still be mixed; and Django fundamentally eliminates coding in templates , the possibility of processing data.

For example, in the asp.net template you can write:

<%

int i;

for(i==0;i< 10;i++){

....

}

%>

Django does not support embedding code similar to the above at all, you can only Use the functions built into its template; this is actually constructing a "new language" for its template; because this "new language" is very simple, its template can also be ported to different platforms.

In most cases, Django's template function is sufficient, but for special (sometimes "special" is not very special) situations, you still need to embed code in the template, then you need to follow its template system Rules for template expansion. Sometimes, a problem that can be solved by writing

directly in the template will become more than a dozen lines of code after using the template extension.

Whether programming in templates is tolerated is the most controversial aspect of Django templates.

Pylons & TurboGears & repoze.bfg

Besides Django, the other big one is Pylons, because TurboGears2.x is based on Pylons, and repoze.bfg is also It has been incorporated into the large project of Pylons project, and TurboGears and repoze.bfg will not be discussed separately later.

The design concepts of Pylons and Django are completely different. Pylons itself only has about two thousand lines of Python code, but it also comes with some third-party modules that are almost used by Pylons. Pylons only provides one rack and options, you can customize it according to your own preferences

With free selection of components such as Template, ORM, form, auth, etc., the system is highly customizable. We often say that Python is a glue language, so we can definitely say that Pylons is a glue framework designed with glue language.

Choosing Pylons is mostly about choosing its freedom. Choosing freedom also indicates that you have chosen a nightmare:

· A learning nightmare, Pylons relies on many third-party libraries, and they are not Made in Pylons, when you learn Pylons, you also have to learn how to use these libraries. The key is that sometimes you don’t know what you want to learn. The learning curve of Pylons is much higher than that of Django, and the official documentation of Pylons has always been the target of criticism. Fortunately, the book The Definitive Guide to Pylons was published later. This situation has been solved Something has changed. For this reason, Pylons was once known as a Python framework only suitable for experts.

· Debugging nightmare, because there are many modules involved, it is difficult to locate the problem once an error occurs. It may be the fault of the program you wrote, or it may be that Pylons is wrong, or SQLAlchemy is wrong, or maybe there is a bug in the formencode, it is very messy anyway. This problem can only be solved if you are familiar with it.

· Upgrading nightmare. To install Pylons, you need to install nearly 20 Python modules, large and small, each with its own version number. If you want to upgrade the Pylons version, any module may have incompatibility issues. Upgrade Basically it's very difficult. So far, reddit's Pylons is still stuck at the

antique version 0.9.6, and SQLAlchemy is still at version 0.5.3, which should have something to do with this.

The integration of Pylons and repoze.bfg may give birth to the next framework that can challenge Django's status.

Tornado & web.py

Tornado (http://www.tornadoweb.org) is an open source framework from Facebook. Its philosophy is almost two extremes from Django. . Tornado is a Web server (this article will not elaborate on this), and it is also a micro-framework similar to web.py. Tornado takes the direction of less but better, and it also provides template functions; although it is not encouraged, the author can allow a small amount of coding in the template (directly embedding a single line of py code).

If compared with asp.net, Tornado is a bit similar and only implements AsyncHttpHandler; apart from that, you need to implement everything yourself.

Well, in fact, it has templates, internationalization support, and even a built-in OAuth/OpenID module to facilitate third-party login. It actually directly implements the HTTP server.

But it does not have an ORM (only a super simple encapsulation of mysql), and it does not even have Session support, let alone an automated backend like Django.

Assume it is a large website. Under the requirement of high performance, each part of the framework often needs to be customized, and there are very few modules that can be reused. For a website developed with Django, each part has been continuously customized. The rest of the Django framework is most likely what tornado can provide from the beginning.

Different paths lead to the same destination.

HTTP server

In order to efficiently implement the Comet/backend asynchronous call to the HTTP interface, Tornado directly embeds the HTTP server.

The front-end can be accessed by the browser without adding apache/lighttpd/nginx, etc.; but it does not fully implement the HTTP 1.1 protocol, so the official document recommends users to use nginx in the front-end and back-end in the production environment Reverse proxy to multiple Tornado instances. Tornado itself is a single-threaded asynchronous network program. When it is started by default, it will run multiple instances according to the number of CPUs; taking full advantage of the multi-core CPU.

Single-threaded asynchronous

Websites basically have database operations, and Tornado is single-threaded, which means that if the database query returns too slowly, the entire server response will be clogged.

Database queries are essentially remote network calls; ideally, these operations would be encapsulated as asynchronous; but Tornado does not provide any support for this. For a system to meet high traffic, it must solve the problem of database query speed!

If there is a query performance problem in the database, no matter how optimized the entire system is, the database will be the bottleneck and slow down the entire system!

Asynchronous does not **essentially** refer to the performance of the system; it just avoids unnecessary waiting for network responses and the CPU consumption of switching threads.

If the database query response is too slow, what needs to be solved is the performance problem of the database; not the front-end web application that calls the database.

For real-time returned data query, ideally it is necessary to ensure that all data is in memory, and the database hard disk IO should be 0; only such query can be fast enough; and if the database query is fast enough, then the front-end web application will not be able to Encapsulating data queries as asynchronous is necessary

.

Even if you use coroutines, asynchronous programs will always increase the complexity of synchronous programs; what needs to be measured is whether dealing with the additional complexity is worth it.

If there are queries on the backend that are too slow to be bypassed, Tornaod’s suggestion is to encapsulate these queries independently in the backend into HTTP interfaces, and then use Tornado’s built-in asynchronous HTTP client to call them.

The above is the detailed content of Get an in-depth understanding of several commonly used Python Web frameworks. For more information, please follow other related articles on the PHP Chinese website!