• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1*******************************
2  HOWTO Use Python in the web
3*******************************
4
5:Author: Marek Kubica
6
7.. topic:: Abstract
8
9   This document shows how Python fits into the web.  It presents some ways
10   to integrate Python with a web server, and general practices useful for
11   developing web sites.
12
13
14Programming for the Web has become a hot topic since the rise of "Web 2.0",
15which focuses on user-generated content on web sites.  It has always been
16possible to use Python for creating web sites, but it was a rather tedious task.
17Therefore, many frameworks and helper tools have been created to assist
18developers in creating faster and more robust sites.  This HOWTO describes
19some of the methods used to combine Python with a web server to create
20dynamic content.  It is not meant as a complete introduction, as this topic is
21far too broad to be covered in one single document.  However, a short overview
22of the most popular libraries is provided.
23
24.. seealso::
25
26   While this HOWTO tries to give an overview of Python in the web, it cannot
27   always be as up to date as desired.  Web development in Python is rapidly
28   moving forward, so the wiki page on `Web Programming
29   <https://wiki.python.org/moin/WebProgramming>`_ may be more in sync with
30   recent development.
31
32
33The Low-Level View
34==================
35
36When a user enters a web site, their browser makes a connection to the site's
37web server (this is called the *request*).  The server looks up the file in the
38file system and sends it back to the user's browser, which displays it (this is
39the *response*).  This is roughly how the underlying protocol, HTTP, works.
40
41Dynamic web sites are not based on files in the file system, but rather on
42programs which are run by the web server when a request comes in, and which
43*generate* the content that is returned to the user.  They can do all sorts of
44useful things, like display the postings of a bulletin board, show your email,
45configure software, or just display the current time.  These programs can be
46written in any programming language the server supports.  Since most servers
47support Python, it is easy to use Python to create dynamic web sites.
48
49Most HTTP servers are written in C or C++, so they cannot execute Python code
50directly -- a bridge is needed between the server and the program.  These
51bridges, or rather interfaces, define how programs interact with the server.
52There have been numerous attempts to create the best possible interface, but
53there are only a few worth mentioning.
54
55Not every web server supports every interface.  Many web servers only support
56old, now-obsolete interfaces; however, they can often be extended using
57third-party modules to support newer ones.
58
59
60Common Gateway Interface
61------------------------
62
63This interface, most commonly referred to as "CGI", is the oldest, and is
64supported by nearly every web server out of the box.  Programs using CGI to
65communicate with their web server need to be started by the server for every
66request.  So, every request starts a new Python interpreter -- which takes some
67time to start up -- thus making the whole interface only usable for low load
68situations.
69
70The upside of CGI is that it is simple -- writing a Python program which uses
71CGI is a matter of about three lines of code.  This simplicity comes at a
72price: it does very few things to help the developer.
73
74Writing CGI programs, while still possible, is no longer recommended.  With
75:ref:`WSGI <WSGI>`, a topic covered later in this document, it is possible to write
76programs that emulate CGI, so they can be run as CGI if no better option is
77available.
78
79.. seealso::
80
81   The Python standard library includes some modules that are helpful for
82   creating plain CGI programs:
83
84   * :mod:`cgi` -- Handling of user input in CGI scripts
85   * :mod:`cgitb` -- Displays nice tracebacks when errors happen in CGI
86     applications, instead of presenting a "500 Internal Server Error" message
87
88   The Python wiki features a page on `CGI scripts
89   <https://wiki.python.org/moin/CgiScripts>`_ with some additional information
90   about CGI in Python.
91
92
93Simple script for testing CGI
94^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
95
96To test whether your web server works with CGI, you can use this short and
97simple CGI program::
98
99    #!/usr/bin/env python
100    # -*- coding: UTF-8 -*-
101
102    # enable debugging
103    import cgitb
104    cgitb.enable()
105
106    print "Content-Type: text/plain;charset=utf-8"
107    print
108
109    print "Hello World!"
110
111Depending on your web server configuration, you may need to save this code with
112a ``.py`` or ``.cgi`` extension.  Additionally, this file may also need to be
113in a ``cgi-bin`` folder, for security reasons.
114
115You might wonder what the ``cgitb`` line is about.  This line makes it possible
116to display a nice traceback instead of just crashing and displaying an "Internal
117Server Error" in the user's browser.  This is useful for debugging, but it might
118risk exposing some confidential data to the user.  You should not use ``cgitb``
119in production code for this reason.  You should *always* catch exceptions, and
120display proper error pages -- end-users don't like to see nondescript "Internal
121Server Errors" in their browsers.
122
123
124Setting up CGI on your own server
125^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
126
127If you don't have your own web server, this does not apply to you.  You can
128check whether it works as-is, and if not you will need to talk to the
129administrator of your web server. If it is a big host, you can try filing a
130ticket asking for Python support.
131
132If you are your own administrator or want to set up CGI for testing purposes on
133your own computers, you have to configure it by yourself.  There is no single
134way to configure CGI, as there are many web servers with different
135configuration options.  Currently the most widely used free web server is
136`Apache HTTPd <http://httpd.apache.org/>`_, or Apache for short. Apache can be
137easily installed on nearly every system using the system's package management
138tool.  `lighttpd <http://www.lighttpd.net>`_ is another alternative and is
139said to have better performance.  On many systems this server can also be
140installed using the package management tool, so manually compiling the web
141server may not be needed.
142
143* On Apache you can take a look at the `Dynamic Content with CGI
144  <http://httpd.apache.org/docs/2.2/howto/cgi.html>`_ tutorial, where everything
145  is described.  Most of the time it is enough just to set ``+ExecCGI``.  The
146  tutorial also describes the most common gotchas that might arise.
147
148* On lighttpd you need to use the `CGI module
149  <http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModCGI>`_\ , which can be configured
150  in a straightforward way.  It boils down to setting ``cgi.assign`` properly.
151
152
153Common problems with CGI scripts
154^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
155
156Using CGI sometimes leads to small annoyances while trying to get these
157scripts to run.  Sometimes a seemingly correct script does not work as
158expected, the cause being some small hidden problem that's difficult to spot.
159
160Some of these potential problems are:
161
162* The Python script is not marked as executable.  When CGI scripts are not
163  executable most web servers will let the user download it, instead of
164  running it and sending the output to the user.  For CGI scripts to run
165  properly on Unix-like operating systems, the ``+x`` bit needs to be set.
166  Using ``chmod a+x your_script.py`` may solve this problem.
167
168* On a Unix-like system, The line endings in the program file must be Unix
169  style line endings.  This is important because the web server checks the
170  first line of the script (called shebang) and tries to run the program
171  specified there.  It gets easily confused by Windows line endings (Carriage
172  Return & Line Feed, also called CRLF), so you have to convert the file to
173  Unix line endings (only Line Feed, LF).  This can be done automatically by
174  uploading the file via FTP in text mode instead of binary mode, but the
175  preferred way is just telling your editor to save the files with Unix line
176  endings.  Most editors support this.
177
178* Your web server must be able to read the file, and you need to make sure the
179  permissions are correct.  On unix-like systems, the server often runs as user
180  and group ``www-data``, so it might be worth a try to change the file
181  ownership, or making the file world readable by using ``chmod a+r
182  your_script.py``.
183
184* The web server must know that the file you're trying to access is a CGI script.
185  Check the configuration of your web server, as it may be configured
186  to expect a specific file extension for CGI scripts.
187
188* On Unix-like systems, the path to the interpreter in the shebang
189  (``#!/usr/bin/env python``) must be correct.  This line calls
190  ``/usr/bin/env`` to find Python, but it will fail if there is no
191  ``/usr/bin/env``, or if Python is not in the web server's path.  If you know
192  where your Python is installed, you can also use that full path.  The
193  commands ``whereis python`` and ``type -p python`` could help you find
194  where it is installed.  Once you know the path, you can change the shebang
195  accordingly: ``#!/usr/bin/python``.
196
197* The file must not contain a BOM (Byte Order Mark). The BOM is meant for
198  determining the byte order of UTF-16 and UTF-32 encodings, but some editors
199  write this also into UTF-8 files.  The BOM interferes with the shebang line,
200  so be sure to tell your editor not to write the BOM.
201
202* If the web server is using :ref:`mod-python`, ``mod_python`` may be having
203  problems.  ``mod_python`` is able to handle CGI scripts by itself, but it can
204  also be a source of issues.
205
206
207.. _mod-python:
208
209mod_python
210----------
211
212People coming from PHP often find it hard to grasp how to use Python in the web.
213Their first thought is mostly `mod_python <http://modpython.org/>`_\ ,
214because they think that this is the equivalent to ``mod_php``.  Actually, there
215are many differences.  What ``mod_python`` does is embed the interpreter into
216the Apache process, thus speeding up requests by not having to start a Python
217interpreter for each request.  On the other hand, it is not "Python intermixed
218with HTML" in the way that PHP is often intermixed with HTML. The Python
219equivalent of that is a template engine.  ``mod_python`` itself is much more
220powerful and provides more access to Apache internals.  It can emulate CGI,
221work in a "Python Server Pages" mode (similar to JSP) which is "HTML
222intermingled with Python", and it has a "Publisher" which designates one file
223to accept all requests and decide what to do with them.
224
225``mod_python`` does have some problems.  Unlike the PHP interpreter, the Python
226interpreter uses caching when executing files, so changes to a file will
227require the web server to be restarted.  Another problem is the basic concept
228-- Apache starts child processes to handle the requests, and unfortunately
229every child process needs to load the whole Python interpreter even if it does
230not use it.  This makes the whole web server slower.  Another problem is that,
231because ``mod_python`` is linked against a specific version of ``libpython``,
232it is not possible to switch from an older version to a newer (e.g. 2.4 to 2.5)
233without recompiling ``mod_python``.  ``mod_python`` is also bound to the Apache
234web server, so programs written for ``mod_python`` cannot easily run on other
235web servers.
236
237These are the reasons why ``mod_python`` should be avoided when writing new
238programs.  In some circumstances it still might be a good idea to use
239``mod_python`` for deployment, but WSGI makes it possible to run WSGI programs
240under ``mod_python`` as well.
241
242
243FastCGI and SCGI
244----------------
245
246FastCGI and SCGI try to solve the performance problem of CGI in another way.
247Instead of embedding the interpreter into the web server, they create
248long-running background processes. There is still a module in the web server
249which makes it possible for the web server to "speak" with the background
250process.  As the background process is independent of the server, it can be
251written in any language, including Python.  The language just needs to have a
252library which handles the communication with the webserver.
253
254The difference between FastCGI and SCGI is very small, as SCGI is essentially
255just a "simpler FastCGI".  As the web server support for SCGI is limited,
256most people use FastCGI instead, which works the same way.  Almost everything
257that applies to SCGI also applies to FastCGI as well, so we'll only cover
258the latter.
259
260These days, FastCGI is never used directly.  Just like ``mod_python``, it is only
261used for the deployment of WSGI applications.
262
263
264Setting up FastCGI
265^^^^^^^^^^^^^^^^^^
266
267Each web server requires a specific module.
268
269* Apache has both `mod_fastcgi <http://www.fastcgi.com/drupal/>`_ and `mod_fcgid
270  <https://httpd.apache.org/mod_fcgid/>`_.  ``mod_fastcgi`` is the original one, but it
271  has some licensing issues, which is why it is sometimes considered non-free.
272  ``mod_fcgid`` is a smaller, compatible alternative.  One of these modules needs
273  to be loaded by Apache.
274
275* lighttpd ships its own `FastCGI module
276  <http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModFastCGI>`_ as well as an
277  `SCGI module <http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModSCGI>`_.
278
279* `nginx <http://nginx.org/>`_ also supports `FastCGI
280  <https://www.nginx.com/resources/wiki/start/topics/examples/simplepythonfcgi/>`_.
281
282Once you have installed and configured the module, you can test it with the
283following WSGI-application::
284
285    #!/usr/bin/env python
286    # -*- coding: UTF-8 -*-
287
288    from cgi import escape
289    import sys, os
290    from flup.server.fcgi import WSGIServer
291
292    def app(environ, start_response):
293        start_response('200 OK', [('Content-Type', 'text/html')])
294
295        yield '<h1>FastCGI Environment</h1>'
296        yield '<table>'
297        for k, v in sorted(environ.items()):
298            yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v))
299        yield '</table>'
300
301    WSGIServer(app).run()
302
303This is a simple WSGI application, but you need to install `flup
304<https://pypi.org/project/flup/1.0>`_ first, as flup handles the low level
305FastCGI access.
306
307.. seealso::
308
309   There is some documentation on `setting up Django with WSGI
310   <https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/>`_, most of
311   which can be reused for other WSGI-compliant frameworks and libraries.
312   Only the ``manage.py`` part has to be changed, the example used here can be
313   used instead.  Django does more or less the exact same thing.
314
315
316mod_wsgi
317--------
318
319`mod_wsgi <http://code.google.com/p/modwsgi/>`_ is an attempt to get rid of the
320low level gateways.  Given that FastCGI, SCGI, and mod_python are mostly used to
321deploy WSGI applications, mod_wsgi was started to directly embed WSGI applications
322into the Apache web server. mod_wsgi is specifically designed to host WSGI
323applications.  It makes the deployment of WSGI applications much easier than
324deployment using other low level methods, which need glue code.  The downside
325is that mod_wsgi is limited to the Apache web server; other servers would need
326their own implementations of mod_wsgi.
327
328mod_wsgi supports two modes: embedded mode, in which it integrates with the
329Apache process, and daemon mode, which is more FastCGI-like.  Unlike FastCGI,
330mod_wsgi handles the worker-processes by itself, which makes administration
331easier.
332
333
334.. _WSGI:
335
336Step back: WSGI
337===============
338
339WSGI has already been mentioned several times, so it has to be something
340important.  In fact it really is, and now it is time to explain it.
341
342The *Web Server Gateway Interface*,  or WSGI for short, is defined in
343:pep:`333` and is currently the best way to do Python web programming.  While
344it is great for programmers writing frameworks, a normal web developer does not
345need to get in direct contact with it.  When choosing a framework for web
346development it is a good idea to choose one which supports WSGI.
347
348The big benefit of WSGI is the unification of the application programming
349interface.  When your program is compatible with WSGI -- which at the outer
350level means that the framework you are using has support for WSGI -- your
351program can be deployed via any web server interface for which there are WSGI
352wrappers.  You do not need to care about whether the application user uses
353mod_python or FastCGI or mod_wsgi -- with WSGI your application will work on
354any gateway interface.  The Python standard library contains its own WSGI
355server, :mod:`wsgiref`, which is a small web server that can be used for
356testing.
357
358A really great WSGI feature is middleware.  Middleware is a layer around your
359program which can add various functionality to it.  There is quite a bit of
360`middleware <https://wsgi.readthedocs.org/en/latest/libraries.html>`_ already
361available.  For example, instead of writing your own session management (HTTP
362is a stateless protocol, so to associate multiple HTTP requests with a single
363user your application must create and manage such state via a session), you can
364just download middleware which does that, plug it in, and get on with coding
365the unique parts of your application.  The same thing with compression -- there
366is existing middleware which handles compressing your HTML using gzip to save
367on your server's bandwidth.  Authentication is another problem that is easily
368solved using existing middleware.
369
370Although WSGI may seem complex, the initial phase of learning can be very
371rewarding because WSGI and the associated middleware already have solutions to
372many problems that might arise while developing web sites.
373
374
375WSGI Servers
376------------
377
378The code that is used to connect to various low level gateways like CGI or
379mod_python is called a *WSGI server*.  One of these servers is ``flup``, which
380supports FastCGI and SCGI, as well as `AJP
381<https://en.wikipedia.org/wiki/Apache_JServ_Protocol>`_.  Some of these servers
382are written in Python, as ``flup`` is, but there also exist others which are
383written in C and can be used as drop-in replacements.
384
385There are many servers already available, so a Python web application
386can be deployed nearly anywhere.  This is one big advantage that Python has
387compared with other web technologies.
388
389.. seealso::
390
391   A good overview of WSGI-related code can be found in the `WSGI homepage
392   <https://wsgi.readthedocs.org/>`_, which contains an extensive list of `WSGI servers
393   <https://wsgi.readthedocs.org/en/latest/servers.html>`_ which can be used by *any* application
394   supporting WSGI.
395
396   You might be interested in some WSGI-supporting modules already contained in
397   the standard library, namely:
398
399   * :mod:`wsgiref` -- some tiny utilities and servers for WSGI
400
401
402Case study: MoinMoin
403--------------------
404
405What does WSGI give the web application developer?  Let's take a look at
406an application that's been around for a while, which was written in
407Python without using WSGI.
408
409One of the most widely used wiki software packages is `MoinMoin
410<https://moinmo.in/>`_.  It was created in 2000, so it predates WSGI by about
411three years.  Older versions needed separate code to run on CGI, mod_python,
412FastCGI and standalone.
413
414It now includes support for WSGI.  Using WSGI, it is possible to deploy
415MoinMoin on any WSGI compliant server, with no additional glue code.
416Unlike the pre-WSGI versions, this could include WSGI servers that the
417authors of MoinMoin know nothing about.
418
419
420Model-View-Controller
421=====================
422
423The term *MVC* is often encountered in statements such as "framework *foo*
424supports MVC".  MVC is more about the overall organization of code, rather than
425any particular API.  Many web frameworks use this model to help the developer
426bring structure to their program.  Bigger web applications can have lots of
427code, so it is a good idea to have an effective structure right from the beginning.
428That way, even users of other frameworks (or even other languages, since MVC is
429not Python-specific) can easily understand the code, given that they are
430already familiar with the MVC structure.
431
432MVC stands for three components:
433
434* The *model*.  This is the data that will be displayed and modified.  In
435  Python frameworks, this component is often represented by the classes used by
436  an object-relational mapper.
437
438* The *view*.  This component's job is to display the data of the model to the
439  user.  Typically this component is implemented via templates.
440
441* The *controller*.  This is the layer between the user and the model.  The
442  controller reacts to user actions (like opening some specific URL), tells
443  the model to modify the data if necessary, and tells the view code what to
444  display,
445
446While one might think that MVC is a complex design pattern, in fact it is not.
447It is used in Python because it has turned out to be useful for creating clean,
448maintainable web sites.
449
450.. note::
451
452   While not all Python frameworks explicitly support MVC, it is often trivial
453   to create a web site which uses the MVC pattern by separating the data logic
454   (the model) from the user interaction logic (the controller) and the
455   templates (the view).  That's why it is important not to write unnecessary
456   Python code in the templates -- it works against the MVC model and creates
457   chaos in the code base, making it harder to understand and modify.
458
459.. seealso::
460
461   The English Wikipedia has an article about the `Model-View-Controller pattern
462   <https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller>`_.  It includes a long
463   list of web frameworks for various programming languages.
464
465
466Ingredients for Websites
467========================
468
469Websites are complex constructs, so tools have been created to help web
470developers make their code easier to write and more maintainable.  Tools like
471these exist for all web frameworks in all languages.  Developers are not forced
472to use these tools, and often there is no "best" tool.  It is worth learning
473about the available tools because they can greatly simplify the process of
474developing a web site.
475
476
477.. seealso::
478
479   There are far more components than can be presented here.  The Python wiki
480   has a page about these components, called
481   `Web Components <https://wiki.python.org/moin/WebComponents>`_.
482
483
484Templates
485---------
486
487Mixing of HTML and Python code is made possible by a few libraries.  While
488convenient at first, it leads to horribly unmaintainable code.  That's why
489templates exist.  Templates are, in the simplest case, just HTML files with
490placeholders.  The HTML is sent to the user's browser after filling in the
491placeholders.
492
493Python already includes two ways to build simple templates::
494
495    >>> template = "<html><body><h1>Hello %s!</h1></body></html>"
496    >>> print template % "Reader"
497    <html><body><h1>Hello Reader!</h1></body></html>
498
499    >>> from string import Template
500    >>> template = Template("<html><body><h1>Hello ${name}</h1></body></html>")
501    >>> print template.substitute(dict(name='Dinsdale'))
502    <html><body><h1>Hello Dinsdale!</h1></body></html>
503
504To generate complex HTML based on non-trivial model data, conditional
505and looping constructs like Python's *for* and *if* are generally needed.
506*Template engines* support templates of this complexity.
507
508There are a lot of template engines available for Python which can be used with
509or without a `framework`_.  Some of these define a plain-text programming
510language which is easy to learn, partly because it is limited in scope.
511Others use XML, and the template output is guaranteed to be always be valid
512XML.  There are many other variations.
513
514Some `frameworks`_ ship their own template engine or recommend one in
515particular.  In the absence of a reason to use a different template engine,
516using the one provided by or recommended by the framework is a good idea.
517
518Popular template engines include:
519
520   * `Mako <http://www.makotemplates.org/>`_
521   * `Genshi <http://genshi.edgewall.org/>`_
522   * `Jinja <http://jinja.pocoo.org/>`_
523
524.. seealso::
525
526   There are many template engines competing for attention, because it is
527   pretty easy to create them in Python.  The page `Templating
528   <https://wiki.python.org/moin/Templating>`_ in the wiki lists a big,
529   ever-growing number of these.  The three listed above are considered "second
530   generation" template engines and are a good place to start.
531
532
533Data persistence
534----------------
535
536*Data persistence*, while sounding very complicated, is just about storing data.
537This data might be the text of blog entries, the postings on a bulletin board or
538the text of a wiki page.  There are, of course, a number of different ways to store
539information on a web server.
540
541Often, relational database engines like `MySQL <http://www.mysql.com/>`_ or
542`PostgreSQL <http://www.postgresql.org/>`_ are used because of their good
543performance when handling very large databases consisting of millions of
544entries.  There is also a small database engine called `SQLite
545<http://www.sqlite.org/>`_, which is bundled with Python in the :mod:`sqlite3`
546module, and which uses only one file.  It has no other dependencies.  For
547smaller sites SQLite is just enough.
548
549Relational databases are *queried* using a language called `SQL
550<https://en.wikipedia.org/wiki/SQL>`_.  Python programmers in general do not
551like SQL too much, as they prefer to work with objects.  It is possible to save
552Python objects into a database using a technology called `ORM
553<https://en.wikipedia.org/wiki/Object-relational_mapping>`_ (Object Relational
554Mapping).  ORM translates all object-oriented access into SQL code under the
555hood, so the developer does not need to think about it.  Most `frameworks`_ use
556ORMs, and it works quite well.
557
558A second possibility is storing data in normal, plain text files (some
559times called "flat files").  This is very easy for simple sites,
560but can be difficult to get right if the web site is performing many
561updates to the stored data.
562
563A third possibility are object oriented databases (also called "object
564databases").  These databases store the object data in a form that closely
565parallels the way the objects are structured in memory during program
566execution.  (By contrast, ORMs store the object data as rows of data in tables
567and relations between those rows.)  Storing the objects directly has the
568advantage that nearly all objects can be saved in a straightforward way, unlike
569in relational databases where some objects are very hard to represent.
570
571`Frameworks`_ often give hints on which data storage method to choose.  It is
572usually a good idea to stick to the data store recommended by the framework
573unless the application has special requirements better satisfied by an
574alternate storage mechanism.
575
576.. seealso::
577
578   * `Persistence Tools <https://wiki.python.org/moin/PersistenceTools>`_ lists
579     possibilities on how to save data in the file system.  Some of these
580     modules are part of the standard library
581
582   * `Database Programming <https://wiki.python.org/moin/DatabaseProgramming>`_
583     helps with choosing a method for saving data
584
585   * `SQLAlchemy <http://www.sqlalchemy.org/>`_, the most powerful OR-Mapper
586     for Python, and `Elixir <https://pypi.org/project/Elixir>`_, which makes
587     SQLAlchemy easier to use
588
589   * `SQLObject <http://www.sqlobject.org/>`_, another popular OR-Mapper
590
591   * `ZODB <https://launchpad.net/zodb>`_ and `Durus
592     <https://www.mems-exchange.org/software/>`_, two object oriented
593     databases
594
595
596.. _framework:
597
598Frameworks
599==========
600
601The process of creating code to run web sites involves writing code to provide
602various services.  The code to provide a particular service often works the
603same way regardless of the complexity or purpose of the web site in question.
604Abstracting these common solutions into reusable code produces what are called
605"frameworks" for web development.  Perhaps the most well-known framework for
606web development is Ruby on Rails, but Python has its own frameworks.  Some of
607these were partly inspired by Rails, or borrowed ideas from Rails, but many
608existed a long time before Rails.
609
610Originally Python web frameworks tended to incorporate all of the services
611needed to develop web sites as a giant, integrated set of tools.  No two web
612frameworks were interoperable:  a program developed for one could not be
613deployed on a different one without considerable re-engineering work.  This led
614to the development of "minimalist" web frameworks that provided just the tools
615to communicate between the Python code and the http protocol, with all other
616services to be added on top via separate components.  Some ad hoc standards
617were developed that allowed for limited interoperability between frameworks,
618such as a standard that allowed different template engines to be used
619interchangeably.
620
621Since the advent of WSGI, the Python web framework world has been evolving
622toward interoperability based on the WSGI standard.  Now many web frameworks,
623whether "full stack" (providing all the tools one needs to deploy the most
624complex web sites) or minimalist, or anything in between, are built from
625collections of reusable components that can be used with more than one
626framework.
627
628The majority of users will probably want to select a "full stack" framework
629that has an active community.  These frameworks tend to be well documented,
630and provide the easiest path to producing a fully functional web site in
631minimal time.
632
633
634Some notable frameworks
635-----------------------
636
637There are an incredible number of frameworks, so they cannot all be covered
638here.  Instead we will briefly touch on some of the most popular.
639
640
641Django
642^^^^^^
643
644`Django <https://www.djangoproject.com/>`_ is a framework consisting of several
645tightly coupled elements which were written from scratch and work together very
646well.  It includes an ORM which is quite powerful while being simple to use,
647and has a great online administration interface which makes it possible to edit
648the data in the database with a browser.  The template engine is text-based and
649is designed to be usable for page designers who cannot write Python.  It
650supports template inheritance and filters (which work like Unix pipes).  Django
651has many handy features bundled, such as creation of RSS feeds or generic views,
652which make it possible to create web sites almost without writing any Python code.
653
654It has a big, international community, the members of which have created many
655web sites.  There are also a lot of add-on projects which extend Django's normal
656functionality.  This is partly due to Django's well written `online
657documentation <https://docs.djangoproject.com/>`_ and the `Django book
658<http://www.djangobook.com/>`_.
659
660
661.. note::
662
663   Although Django is an MVC-style framework, it names the elements
664   differently, which is described in the `Django FAQ
665   <https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names>`_.
666
667
668TurboGears
669^^^^^^^^^^
670
671Another popular web framework for Python is `TurboGears
672<http://www.turbogears.org/>`_.  TurboGears takes the approach of using already
673existing components and combining them with glue code to create a seamless
674experience.  TurboGears gives the user flexibility in choosing components. For
675example the ORM and template engine can be changed to use packages different
676from those used by default.
677
678The documentation can be found in the `TurboGears documentation
679<https://turbogears.readthedocs.org/>`_, where links to screencasts can be found.
680TurboGears has also an active user community which can respond to most related
681questions.  There is also a `TurboGears book <http://turbogears.org/1.0/docs/TGBooks.html>`_
682published, which is a good starting point.
683
684The newest version of TurboGears, version 2.0, moves even further in direction
685of WSGI support and a component-based architecture.  TurboGears 2 is based on
686the WSGI stack of another popular component-based web framework, `Pylons
687<http://www.pylonsproject.org/>`_.
688
689
690Zope
691^^^^
692
693The Zope framework is one of the "old original" frameworks.  Its current
694incarnation in Zope2 is a tightly integrated full-stack framework.  One of its
695most interesting feature is its tight integration with a powerful object
696database called the `ZODB <https://launchpad.net/zodb>`_ (Zope Object Database).
697Because of its highly integrated nature, Zope wound up in a somewhat isolated
698ecosystem:  code written for Zope wasn't very usable outside of Zope, and
699vice-versa.  To solve this problem the Zope 3 effort was started.  Zope 3
700re-engineers Zope as a set of more cleanly isolated components.  This effort
701was started before the advent of the WSGI standard, but there is WSGI support
702for Zope 3 from the `Repoze <http://repoze.org/>`_ project.  Zope components
703have many years of production use behind them, and the Zope 3 project gives
704access to these components to the wider Python community.  There is even a
705separate framework based on the Zope components: `Grok
706<http://grok.zope.org/>`_.
707
708Zope is also the infrastructure used by the `Plone <https://plone.org/>`_ content
709management system, one of the most powerful and popular content management
710systems available.
711
712
713Other notable frameworks
714^^^^^^^^^^^^^^^^^^^^^^^^
715
716Of course these are not the only frameworks that are available.  There are
717many other frameworks worth mentioning.
718
719Another framework that's already been mentioned is `Pylons`_.  Pylons is much
720like TurboGears, but with an even stronger emphasis on flexibility, which comes
721at the cost of being more difficult to use.  Nearly every component can be
722exchanged, which makes it necessary to use the documentation of every single
723component, of which there are many.  Pylons builds upon `Paste
724<http://pythonpaste.org/>`_, an extensive set of tools which are handy for WSGI.
725
726And that's still not everything.  The most up-to-date information can always be
727found in the Python wiki.
728
729.. seealso::
730
731   The Python wiki contains an extensive list of `web frameworks
732   <https://wiki.python.org/moin/WebFrameworks>`_.
733
734   Most frameworks also have their own mailing lists and IRC channels, look out
735   for these on the projects' web sites.
736