0
点赞
收藏
分享

微信扫一扫

python的现状与未来

1.1 Python 的现状与未来

Python 的历史最早可追溯到 20 世纪 80 年代末,但是 1.0 版的发行时间是在 1994 年, 所以 Python 并不是一门非常年轻的语言。这里本该介绍 Python 主要版本发布的整个时间 线,但其实真正重要的日期只有一个:2008 年 12 月 3 日,也就是 Python 3.0 的发布日期。

在写作本书时,Python 3 的首次发布已经过去了 7 年。PEP 404 也已经创建了 4 年,PEP

第1章 Python 现状

2 第1章 Python现状

404是“取消发布"(un-release)Python 2.8并正式关闭Python 2.x分支的官方文档。虽然 过去了这么长的时间,Python 社区中依然存在明显的分歧。语言本身在迅速发展,但大量 用户却并不想更新版本。

1.2 Python 升级及其原因

原因很简单。Python 升级是因为有这样的需求。语言之间的竞争随时都在上演。每隔 几个月都会突然冒出一门新语言,声称解决了之前所有语言中存在的问题。对于大多数类 似的项目,开发人员很快就会失去兴趣,它们的名气也只是一时炒作。

不管怎样,这也表示存在着更严重的问题。人们之所以设计新的编程语言,是因为他 们发现现有的语言无法以最佳方式来解决问题。认识不到这样的需求是目光短浅的。此外, Python 的使用范围也越来越广泛,人们发现它有许多可以改进的地方,也应该做出这样的 改进。

Python 的很多改进往往是由特定应用领域的需求驱动的。其中最重要的领域是 Web 开 发,这一领域需要 Python 改进对并发的处理。

有些变化只是由于 Python 项目的历史原因导致的。这些年已经发现了 Python 的一些 不合理之处,有些是标准库模块结构混乱或冗余,有些是程序设计缺陷。最初,发布 Python 3 是要对这门语言进行较大的清理与更新,但结果显示,这个计划并没有收到预期的效果。 在很长一段时间内,很多开发人员对 Python 3 只是抱着好奇的态度而已,但希望这种情形 正在好转。

1.3 追踪 Python 最新变化——PEP 文档

Python社区有一种应对变化的固定方法。虽然各种各样的Python语言修改意见主要在 邮件列表(python-ideas@python.org)中进行讨论,但只有发布了名为 PEP 的新文 档,新的变化才会生效。PEP 的全称是 Python 改进提案(Python Enhancement Proposal, PEP)。它是提交 Python 变化的书面文档,也是社区对这一变化进行讨论的出发点。这些文 档的整个目的、格式和工作流程的标准格式也都包含在一份 Python 改进提案中,也就是 PEP 1 文档(http://www.python.org/dev/peps/pep-0001)。

PEP 文档对 Python 的作用十分重要,根据讨论的主题,PEP 主要有以下 3 种用途。 • 通知:汇总 Python 核心开发者需要的信息,并通知 Python 发布日程。

• 标准化:提供代码风格、文档或其他指导意见。

• 设计:对提交的功能进行说明。


所有提交过的 PEP 都被汇总在一个文档中,就是 PEP 0(https://www.python.org/dev/peps/)。 由于这些 PEP 都在同一个网站上很容易找到,其 URL 也很容易猜到,因此本书一般用编 号来指代这些文档。

如果你对 Python 语言的未来发展方向感兴趣,但又没时间跟踪 Python 邮件列表中的 讨论,那么PEP 0会是很好的信息来源。它会告诉你,哪些文档已被接受但尚未实施,哪 些文档仍在审议中。

PEP 还有其他的用途。人们通常会问这样的问题:

• A 功能为什么要以这样的方式运行?

• Python 为什么没有 B 功能?

大多数情况下,关于该功能的某个 PEP 文档已经给出了上述问题的详细回答。很多提

交的关于 Python 语言功能的 PEP 文档并没有通过。这些文档可作为历史资料来参考。

1.4 当前 Python 3 的普及程度

Python 3有许多强大的新功能,那么它在社区中广泛普及了吗?遗憾的是,并没有。 有一个著名的网站叫“Python 3 荣耀之墙(Python 3 Wall of Superpowers)”,里面记录了大 多数常用软件包与 Python 3 的兼容性,不久前这个网站刚刚改名为“Python 3 耻辱之墙

(Python 3 Wall of Shame)”。目前这种状况正在逐步改善,上述网站的软件包列表中绿色的 比例也在每月缓慢增加1。尽管如此,但这并不代表很快所有应用开发团队都只使用 Python 3。当所有常用软件包都支持 Python 3 时,“我们所用的软件包还没有迁移到 Python 3”这 一常用借口将不再适用。

造成目前这种状况的主要原因是,将现有应用从 Python 2 迁移到 Python 3 上总是一项 不小的挑战。像 2to3 之类的工具可以进行代码自动转换,但无法保证转换后的代码 100% 正确。而且,如果不做人工修改的话,转换后的代码性能可能不如转换前。将现有的复杂 代码库迁移到 Python 3 上可能需要付出巨大的精力和成本,某些公司可能无法负担这些成 本。但这些成本可以分割成小份来逐步完成。一些优秀的软件架构设计方法可以帮助其逐 步实现这一目标,如面向服务的架构或者微服务。新的项目组件(服务或微服务)可以用 新方法编写,现有的项目组件可以逐步迁移。

长远来看,将项目迁移到Python 3只有好处。根据PEP-404这份文档,Python 2.x分 支将不会发布 2.8 版本。而且未来所有重要的项目(如 Django、Flask 和 NumPy)可能都 将放弃 2.x 的兼容性,仅支持 Python 3。

1.4 当前Python 3的普及程度 3

 1 在这个网站上,如果某个软件包被标为绿色,则表示它支持 Python 3,红色则表示不支持。— 译者注


4 第1章 Python现状

我个人对这个问题的观点可能会引发争议。我认为在创建新的软件包时,最好鼓励社 区完全放弃支持Python 2。当然,这一做法极大地限制了这些软件的适用范围,但对于那 些坚持使用 Python 2.x 的人来说,这可能是改变他们想法的唯一方法。

举报

相关推荐

0 条评论