如何在网络中使用 Python

• Author

  • Marek Kubica

Abstract

本文档说明了 Python 如何适应网络。它介绍了将 Python 与 Web 服务器集成的一些方法，以及对开发 Web 站点有用的一般做法。

自“ Web 2.0”兴起以来，Web 编程已成为热门 Topic，Web 2.0 侧重于网站上用户生成的内容。始终可以使用 Python 创建网站，但这是一个非常繁琐的任务。因此，已经创建了许多框架和帮助工具来帮助开发人员创建更快，更强大的站点。本 HOWTO 描述了一些用于将 Python 与 Web 服务器结合以创建动态内容的方法。这并不意味着要进行完整的介绍，因为该主题范围太广，无法在一个文档中涵盖。但是，提供了最流行的库的简短概述。

低层视图

当用户进入网站时，他们的浏览器将连接到该网站的 Web 服务器(称为* request )。服务器在文件系统中查找文件，然后将其发送回用户的浏览器，由浏览器显示(这是 response *)。底层协议 HTTP 大致是这样工作的。

动态网站不是基于文件系统中的文件，而是基于在请求进入时由 Web 服务器运行并“生成”返回给用户的内容的程序。他们可以做各种有用的事情，例如显示公告板的post，显示您的电子邮件，配置软件或仅显示当前时间。这些程序可以用服务器支持的任何编程语言编写。由于大多数服务器都支持 Python，因此使用 Python 创建动态网站很容易。

大多数 HTTP 服务器都是用 C 或 C 编写的，因此它们无法直接执行 Python 代码-服务器与程序之间需要一座 bridge 梁。这些 bridge 或接口，定义了程序如何与服务器交互。已经进行了许多try来创建可能的最佳界面，但是只有少数值得一提。

并非每个 Web 服务器都支持每个接口。许多 Web 服务器仅支持旧的，现在已经过时的界面；但是，通常可以使用第三方模块来扩展它们以支持更新的模块。

通用网关接口

这个界面，最通常称为“ CGI”，是最古老的，几乎所有开箱即用的 Web 服务器都支持。服务器需要为每个请求启动使用 CGI 与 Web 服务器通信的程序。因此，每个请求都会启动一个新的 Python 解释器(这需要一些时间才能启动)，从而使整个接口仅适用于低负载情况。

CGI 的好处在于它很简单–编写使用 CGI 的 Python 程序大约需要三行代码。这种简单性是有代价的：它对开发人员的帮助很少。

尽管仍然可以编写 CGI 程序，但不再建议这样做。使用WSGI(本文档后面将介绍的主题)，可以编写模拟 CGI 的程序，因此，如果没有更好的选择，它们可以作为 CGI 运行。

用于测试 CGI 的简单脚本

要测试您的 Web 服务器是否可以与 CGI 一起使用，可以使用以下简短的 CGI 程序：

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

# enable debugging
import cgitb
cgitb.enable()

print "Content-Type: text/plain;charset=utf-8"
print

print "Hello World!"

根据您的 Web 服务器配置，您可能需要使用.py或.cgiextensions 保存此代码。此外，出于安全原因，此文件可能还需要位于cgi-bin文件夹中。

您可能想知道cgitb行是关于什么的。这行代码可以显示一个不错的回溯，而不仅仅是崩溃并在用户的浏览器中显示“内部服务器错误”。这对于调试很有用，但可能会给用户暴露一些机密数据的风险。因此，您不应在生产代码中使用cgitb。您应该总是捕获异常，并显示正确的错误页面-finally用户不喜欢在浏览器中看到非描述性的“内部服务器错误”。

在您自己的服务器上设置 CGI

如果您没有自己的 Web 服务器，则这不适用于您。您可以检查它是否按原样工作，否则，您需要与 Web 服务器的 Management 员联系。如果主机很大，则可以try提交票证以寻求 Python 支持。

如果您是您自己的 Management 员，或者想在自己的计算机上设置 CGI 以进行测试，则必须自己配置它。没有许多方法可以配置 CGI，因为许多 Web 服务器具有不同的配置选项。当前，使用最广泛的免费 Web 服务器是Apache HTTPd，简称 Apache。使用系统的程序包 Management 工具，可以将 Apache 轻松安装在几乎每个系统上。 lighttpd是另一种替代方法，据说具有更好的性能。在许多系统上，也可以使用软件包 Management 工具安装此服务器，因此可能不需要手动编译 Web 服务器。

• 在 Apache 上，您可以查看使用 CGI 的动态内容教程，其中描述了所有内容。在大多数情况下，仅设置+ExecCGI就足够了。本教程还描述了可能出现的最常见陷阱。

• 在 lighttpd 上，您需要使用CGI module，可以直接配置它。归结为正确设置cgi.assign。

CGI 脚本的常见问题

在try使这些脚本运行时，使用 CGI 有时会引起一些小麻烦。有时看似正确的脚本无法按预期工作，原因是一些难以发现的小隐患。

这些潜在问题包括：

• Python 脚本未标记为可执行文件。当 CGI 脚本不可执行时，大多数 Web 服务器将允许用户下载它，而不是运行它并将输出发送给用户。为了使 CGI 脚本在类似 Unix 的 os 上正常运行，需要设置+x位。使用chmod a+x your_script.py可以解决此问题。

• 在类 Unix 系统上，程序文件中的行尾必须是 Unix 样式的行尾。这很重要，因为 Web 服务器会检查脚本的第一行(称为 shebang)并try运行此处指定的程序。 Windows 的行尾(回车和换行，也称为 CRLF)容易使它感到困惑，因此您必须将文件转换为 Unix 的行尾(仅换行，LF)。可以pass FTP 以文本模式而不是二进制模式上载文件来自动完成此操作，但是首选方法是告诉您的编辑器以 Unix 行结尾保存文件。大多数编辑器都支持这一点。

• 您的 Web 服务器必须能够读取该文件，并且您需要确保权限正确。在类 unix 的系统上，服务器通常以用户和组www-data的身份运行，因此可能值得try更改文件所有权，或使用chmod a+r your_script.py使文件对世界可读。

• Web 服务器必须知道您要访问的文件是 CGI 脚本。检查 Web 服务器的配置，因为它可能已配置为期望 CGI 脚本具有特定的文件 extensions。

• 在类似 Unix 的系统上，shebang(#!/usr/bin/env python)中解释器的路径必须正确。此行调用/usr/bin/env来查找 Python，但是如果没有/usr/bin/env或 Web 服务器路径中没有 Python，它将失败。如果您知道 Python 的安装位置，则也可以使用完整路径。 whereis python和type -p python命令可以帮助您找到它的安装位置。知道路径后，您可以相应地更改 shebang：#!/usr/bin/python。

• 该文件不得包含 BOM(字节 Sequences 标记)。 BOM 用于确定 UTF-16 和 UTF-32 编码的字节 Sequences，但是一些编辑器也将其写入 UTF-8 文件。 BOM 会干扰 shebang 行，因此请确保告诉编辑器不要编写 BOM。

• 如果 Web 服务器正在使用mod_python，则mod_python可能有问题。 mod_python能够单独处理 CGI 脚本，但是它也可能成为问题的根源。

mod_python

来自 PHP 的人们经常发现很难掌握如何在网络中使用 Python。他们的第一个想法主要是mod_python，因为他们认为这等效于mod_php。实际上，有很多差异。 mod_python的作用是将解释器嵌入到 Apache 进程中，从而不必为每个请求启动 Python 解释器，从而加快了请求的速度。另一方面，它不是“ PHP 与 HTML 混合”，而 PHP 通常与 HTML 混合。相当于 Python 的是模板引擎。 mod_python本身Function更强大，并提供对 Apache 内部的更多访问。它可以模拟 CGI，可以在“ HTML 与 Python 混合”的“ Python 服务器页面”模式(类似于 JSP)下工作，并且具有“发布者”，它可以指定一个文件来接受所有请求并决定如何处理它们。 。

mod_python确实有一些问题。与 PHP 解释器不同，Python 解释器在执行文件时使用缓存，因此对文件的更改将需要重新启动 Web 服务器。另一个问题是基本概念– Apache 启动子进程来处理请求，不幸的是，每个子进程都需要加载整个 Python 解释器，即使它不使用它。这会使整个 Web 服务器变慢。另一个问题是，由于mod_python是与libpython的特定版本链接的，因此，如果不重新编译mod_python，就不可能从较旧的版本切换到较新的版本(例如 2.4 到 2.5)。 mod_python也绑定到 Apache Web 服务器，因此为mod_python编写的程序无法轻松在其他 Web 服务器上运行。

这些就是编写新程序时应避免使用mod_python的原因。在某些情况下，使用mod_python进行部署仍然是一个好主意，但是 WSGI 使得也可以在mod_python下运行 WSGI 程序。

FastCGI 和 SCGI

FastCGI 和 SCGI try以另一种方式解决 CGI 的性能问题。它们没有创建解释器到 Web 服务器中，而是创建了长时间运行的后台进程。 Web 服务器中仍然存在一个模块，该模块使 Web 服务器可以与后台进程“对话”。由于后台进程独立于服务器，因此可以用任何语言(包括 Python)编写。该语言只需要有一个库即可处理与 Web 服务器的通信。

FastCGI 和 SCGI 之间的差异很小，因为 SCGI 本质上只是“简单的 FastCGI”。由于 Web 服务器对 SCGI 的支持有限，因此大多数人改用 FastCGI，其工作方式相同。几乎适用于 SCGI 的所有内容也同样适用于 FastCGI，因此我们仅讨论后者。

如今，FastCGI 从未直接使用过。就像mod_python一样，它仅用于 WSGI 应用程序的部署。

设置 FastCGI

每个 Web 服务器都需要一个特定的模块。

• Apache 同时拥有mod_fastcgi和mod_fcgid。 mod_fastcgi是原始版本，但存在一些许可问题，因此有时被认为是非免费的。 mod_fcgid是较小的兼容替代项。这些模块之一需要由 Apache 加载。

• lighttpd 会提供自己的FastCGI module和SCGI module。

• nginx也支持FastCGI。

一旦安装并配置了模块，就可以使用以下 WSGI 应用程序对其进行测试：

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

from cgi import escape
import sys, os
from flup.server.fcgi import WSGIServer

def app(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])

    yield '<h1>FastCGI Environment</h1>'
    yield '<table>'
    for k, v in sorted(environ.items()):
        yield '<tr><th>%s</th><td>%s</td></tr>' % (escape(k), escape(v))
    yield '</table>'

WSGIServer(app).run()

这是一个简单的 WSGI 应用程序，但是您需要首先安装flup，因为 flup 会处理低级的 FastCGI 访问。

mod_wsgi

mod_wsgi试图摆脱低级网关。鉴于 FastCGI，SCGI 和 mod_python 主要用于部署 WSGI 应用程序，因此开始使用 mod_wsgi 将 WSGI 应用程序直接嵌入 Apache Web 服务器中。 mod_wsgi 是专门为承载 WSGI 应用程序而设计的。与使用其他需要粘合代码的低级方法进行部署相比，它使 WSGI 应用程序的部署更加容易。缺点是 mod_wsgi 仅限于 Apache Web 服务器。其他服务器将需要自己的 mod_wsgi 实现。

mod_wsgi 支持两种模式：嵌入式模式(与 Apache 进程集成)和守护程序模式(类似于 FastCGI)。与 FastCGI 不同，mod_wsgi 自己处理工作进程，这使 Management 更加容易。

后退：WSGI

WSGI 已经被多次提及，因此它必须是重要的。实际上确实如此，现在该解释一下了。

“ Web 服务器网关接口”(简称 WSGI)在 PEP 333中定义，目前是进行 Python Web 编程的最佳方法。尽管这对程序员编写框架非常有用，但是普通的 Web 开发人员无需直接与之联系。选择用于 Web 开发的框架时，最好选择一个支持 WSGI 的框架。

WSGI 的最大好处是统一了应用程序编程接口。当您的程序与 WSGI 兼容时-从外部层次上说，您正在使用的框架支持 WSGI-您的程序可以pass任何有 WSGI 包装器的 Web 服务器接口进行部署。您无需担心应用程序用户是使用 mod_python 还是 FastCGI 或 mod_wsgi –使用 WSGI，您的应用程序可以在任何网关接口上运行。 Python 标准库包含其自己的 WSGI 服务器wsgiref，该服务器是可用于测试的小型 Web 服务器。

中间件是 WSGI 的一项 true 出色的Function。中间件是程序周围的一层，可以向其中添加各种Function。已有许多middleware可用。例如，您无需下载自己的会话 Management(HTTP 是一种 Stateless 协议，因此要将多个 HTTP 请求与单个用户关联，您的应用程序必须pass会话来创建和 Management 这种状态)，您只需下载执行此操作的中间件即可它，然后 continue 对应用程序的独特部分进行编码。压缩也是一样–现有的中间件可以使用 gzip 压缩 HTML，以节省服务器带宽。身份验证是使用现有中间件可以轻松解决的另一个问题。

尽管 WSGI 看起来很复杂，但是学习的初始阶段可能会非常有意义，因为 WSGI 和相关的中间件已经拥有解决网站开发过程中可能出现的许多问题的解决方案。

WSGI Servers

用于连接到各种低级网关(如 CGI 或 mod_python)的代码称为* WSGI 服务器*。这些服务器之一是flup，它支持 FastCGI 和 SCGI 以及AJP。这些服务器中的一些服务器是使用flup的 Python 语言编写的，但也有其他服务器使用 C 语言编写的并且可以用作临时替代品。

已经有许多服务器可用，因此 Python Web 应用程序几乎可以部署在任何地方。与其他 Web 技术相比，这是 Python 的一大优势。

案例研究：MoinMoin

WSGI 给 Web 应用程序开发人员带来了什么？让我们看一下已经存在一段时间的应用程序，它是用 Python 编写的，没有使用 WSGI。

MoinMoin是最广泛使用的 Wiki 软件包之一。它创建于 2000 年，因此比 WSGI 早了三年。较旧的版本需要单独的代码才能在 CGI，mod_python，FastCGI 和独立版本上运行。

现在，它包括对 WSGI 的支持。使用 WSGI，可以将 MoinMoin 部署在任何符合 WSGI 的服务器上，而无需其他附加代码。与 WSGI 之前的版本不同，它可能包括 MoinMoin 的作者一无所知的 WSGI 服务器。

Model-View-Controller

在诸如“框架* foo 支持 MVC”的语句中经常遇到术语 MVC *。 MVC 更多地是关于代码的整体组织，而不是任何特定的 API。许多 Web 框架使用此模型来帮助开发人员将结构引入其程序。较大的 Web 应用程序可以包含很多代码，因此从一开始就具有有效的结构是一个好主意。这样，即使其他框架的用户(甚至其他语言，因为 MVC 不是特定于 Python 的)，也可以轻松理解代码，因为他们已经熟悉 MVC 结构。

MVC 代表三个组成部分：

• 该模型* 。这是将显示和修改的数据。在 Python 框架中，此组件通常由对象关系 Map 器使用的类表示。

• 风景* 。该组件的工作是向用户显示模型数据。通常，此组件是pass模板实现的。

• 控制器。这是用户和模型之间的层。控制器会响应用户的操作(例如打开某些特定的 URL)，告诉模型必要时修改数据，并告诉视图代码显示什么，

尽管人们可能认为 MVC 是一种复杂的设计模式，但实际上并非如此。它在 Python 中使用是因为事实证明它对于创建干净，可维护的网站很有用。

网站的成分

网站是复杂的结构，因此创建了一些工具来帮助 Web 开发人员使他们的代码更易于编写和维护。此类工具适用于所有语言的所有 Web 框架。开发人员不会被迫使用这些工具，并且通常没有“最佳”工具。值得学习可用的工具，因为它们可以大大简化网站开发过程。

Templates

一些库可以实现 HTML 和 Python 代码的混合。虽然起初很方便，但它却导致了无法维护的代码。这就是模板存在的原因。在最简单的情况下，模板就是带有占位符的 HTML 文件。填写占位符后，HTML 将发送到用户的浏览器。

Python 已经包含了两种构建简单模板的方法：

>>> template = "<html><body><h1>Hello %s!</h1></body></html>"
>>> print template % "Reader"
<html><body><h1>Hello Reader!</h1></body></html>

>>> from string import Template
>>> template = Template("<html><body><h1>Hello ${name}</h1></body></html>")
>>> print template.substitute(dict(name='Dinsdale'))
<html><body><h1>Hello Dinsdale!</h1></body></html>

为了基于非平凡的模型数据生成复杂的 HTML，通常需要条件结构和循环结构，例如 Python 的* for 和 if *。 模板引擎支持这种复杂性的模板。

有许多可用于 Python 的模板引擎，可以与framework或不与framework一起使用。其中一些定义了易于学习的纯文本编程语言，部分原因是它的范围受到限制。其他人使用 XML，并且保证模板输出始终是有效的 XML。还有许多其他变体。

一些frameworks会提供自己的模板引擎，或者特别推荐一个。在没有理由使用其他模板引擎的情况下，最好使用框架提供或推荐的模板引擎。

流行的模板引擎包括：

Data persistence

数据持久性虽然听起来很复杂，但仅用于存储数据。此数据可能是博客条目的文本，公告板上的post或 Wiki 页面的文本。当然，有许多不同的方法可以将信息存储在 Web 服务器上。

通常，使用关系数据库引擎(例如MySQL或PostgreSQL)是因为它们在处理包含数百万个条目的超大型数据库时的良好性能。还有一个名为SQLite的小型数据库引擎，该引擎与sqlite3模块中的 PythonBinding 在一起，并且仅使用一个文件。它没有其他依赖项。对于较小的站点，SQLite 就足够了。

使用称为SQL的语言查询关系数据库。通常，Python 程序员不太喜欢 SQL，因为他们更喜欢使用对象。可以使用ORM(对象关系 Map)技术将 Python 对象保存到数据库中。 ORM 在后台将所有面向对象的访问转换为 SQL 代码，因此开发人员无需考虑它。大多数frameworks使用 ORM，并且效果很好。

第二种可能性是将数据存储在普通的纯文本文件中(有时称为“平面文件”)。这对于简单的网站来说非常容易，但是如果网站对存储的数据执行许多更新，则可能很难正确处理。

第三种可能性是面向对象的数据库(也称为“对象数据库”)。这些数据库以与程序执行期间对象在内存中的结构方式非常相似的形式存储对象数据。 (相反，ORM 将对象数据存储为表中的数据行以及这些行之间的关系.)直接存储对象的优点是，几乎所有对象都可以以简单的方式保存，这与关系数据库中某些对象非常相似的情况不同很难代表。

Frameworks经常提示选择哪种数据存储方法。坚持使用框架推荐的数据存储区通常是一个好主意，除非应用程序具有pass替代存储机制更好地满足的特殊要求。

Frameworks

创建代码以运行网站的过程涉及编写代码以提供各种服务。不管所讨论的网站的复杂性或目的如何，提供特定服务的代码通常都以相同的方式工作。将这些常见的解决方案抽象为可重用的代码会产生用于 Web 开发的“框架”。也许最著名的 Web 开发框架是 Ruby on Rails，但是 Python 有自己的框架。其中一些是部分受 Rails 启发或借鉴了 Rails 的思想，但是许多存在于 Rails 之前已有很长时间了。

最初，Python Web 框架倾向于将开发网站所需的所有服务合并为庞大的集成工具集。没有两个 Web 框架可以互操作：为一个开发的程序，如果不进行大量的重新设计工作，就无法部署到另一个程序上。这导致了“极简主义” Web 框架的开发，该框架仅提供在 Python 代码和 http 协议之间进行通信的工具，而所有其他服务则pass单独的组件添加到顶部。已开发了一些临时标准，这些标准允许框架之间的互操作性受到限制，例如允许不同模板引擎可互换使用的标准。

自 WSGI 出现以来，Python Web 框架界一直在朝着基于 WSGI 标准的互操作性 Developing。现在，无论是“全栈”(提供部署最复杂的网站所需的所有工具)还是极简主义或介于两者之间的任何事物的许多 Web 框架都是pass可与多个框架一起使用的可重用组件的集合构建的。

大多数用户可能希望选择一个具有活跃社区的“全栈”框架。这些框架往往有充分的文档记录，并提供了在最短的时间内生成Function齐全的网站的最简单途径。

一些著名的框架

框架数量众多，因此此处不能一一涵盖。相反，我们将简要介绍一些最受欢迎的内容。

Django

Django是一个框架，由几个紧密耦合的元素组成，这些元素是从头开始编写的，可以很好地协同工作。它包含一个 ORM，该 ORM Function强大且易于使用，并且具有出色的在线 Management 界面，可使用浏览器编辑数据库中的数据。模板引擎是基于文本的，旨在供无法编写 Python 的页面设计人员使用。它支持模板继承和过滤器(类似于 Unix 管道)。 DjangoBinding 了许多方便的Function，例如创建 RSS feed 或通用视图，这使得几乎无需编写任何 Python 代码即可创建网站。

它拥有一个庞大的国际社区，其成员创建了许多网站。还有很多扩展 Django 正常Function的附加项目。这部分是由于 Django 的online documentation和Django book写得很好。

TurboGears

另一个流行的 Python Web 框架是TurboGears。 TurboGears 采用了使用现有组件并将它们与粘合代码结合在一起的方法，以创建无缝的体验。 TurboGears 使用户可以灵活选择组件。例如，可以将 ORM 和模板引擎更改为使用与默认使用的软件包不同的软件包。

可以在TurboGears documentation中找到该文档，在其中可以找到指向截屏视频的链接。 TurboGears 还拥有一个活跃的用户社区，可以回答大多数相关问题。还有一个TurboGears book发布，这是一个很好的起点。

最新版本的 TurboGears(版本 2.0)朝着 WSGI 支持和基于组件的体系结构的方向进一步 Developing。 TurboGears 2 基于另一个流行的基于组件的 Web 框架Pylons的 WSGI 堆栈。

Zope

Zope 框架是“旧的原始”框架之一。当前在 Zope2 中的化身是紧密集成的全栈框架。它最有趣的Function之一是与Function强大的对象数据库ZODB(Zope 对象数据库)紧密集成。由于其高度集成的特性，Zope 陷入了一个孤立的生态系统：为 Zope 编写的代码在 Zope 之外不是非常有用，反之亦然。为了解决这个问题，Zope 3 开始了工作。 Zope 3 将 Zope 重新设计为一组更干净隔离的组件。这项工作是在 WSGI 标准问世之前开始的，但是Repoze项目已经为 Zope 3 提供了 WSGI 支持。 Zope 组件在其后面已有多年的生产使用，并且 Zope 3 项目使更广泛的 Python 社区可以访问这些组件。甚至还有一个基于 Zope 组件的单独框架：Grok。

Zope 也是Plone内容 Management 系统使用的基础架构，该系统是可用的最强大和最受欢迎的内容 Management 系统之一。

其他值得注意的框架

当然，这些并不是唯一可用的框架。还有许多其他框架值得一提。

已经提到的另一个框架是Pylons。定向塔很像 TurboGears，但是更加强调灵 Active，这是以更难以使用为代价的。几乎每个组件都可以交换，这使得有必要使用每个组件的文档，其中每个组件都有很多。 Pylons 构建在Paste的基础上，后者是 WSGI 的便捷工具。

但这还不是全部。始终可以在 Python Wiki 中找到最新信息。