通过放宽其相当严格的会员流程，Python 软件基金会开始发展壮大。而 Red Hat 工程运营部门的配置架构师 Nick Coghlan 对此感到非常高兴。
Coghlan 最近在基金会的董事会中获得了一个席位，他将在那里帮助监督这个开源编程语言的管理机构。他在 Python 的关键时刻就任此职。许多备受瞩目的 Linux 发行版开始默认提供 Python 3，鼓励开发人员过渡到最新版本，因为 Python 2 的支持正在减少。PSF 正在改变其会员结构——使世界各地的开发人员更容易加入。
Coghlan 欢迎该组织转向更大的包容性。Coghlan 自 2002 年起成为 Python 用户，当时他在澳大利亚波音公司的高频现代化项目工作，并于 2005 年加入 PSF。但当时，他说，基金会的会员流程并没有完全体现最初吸引他加入 Python 的价值观。
“我第一次加入 PSF 是在成为 CPython 核心开发人员后不久，”Coghlan 说。“当时，PSF 会员资格仍然是‘仅限邀请’。”
但他表示，随着基金会的开放，这种情况正在改变。
“PSF 已过渡到开放会员模式，这更好地符合我们对发展全球 Python 社区的承诺，”Coghlan 说。
当 Coghlan 适应他的新角色时，他向我们解释了 Python 及其社区目前面临的挑战，并阐述了他未来的计划。
什么是 Python 软件基金会？其董事会的职责是什么？
Python 软件基金会是一家位于美国的非营利组织，我们的使命是“推广、保护和发展 Python 编程语言，并支持和促进多元化和国际化的 Python 程序员社区的成长。”
董事会的角色是作为会员的民选代表，决定如何最好地实现这一使命。目前，我们的主要重点是完成从以前的封闭会员模式（新的 PSF 会员必须由现有会员邀请才能加入）到当前的模式的过渡，在当前的模式中，会员资格向任何希望加入的人开放。虽然会员模式的核心变更已经发生，但在工作组的管理方式和贡献的认可方面，还有一些相关的变更仍需要落实到位。
从日常角度来看，董事会还直接负责审查提交给 PSF 的大多数资助提案，并寻找更多机会来改进我们为更广泛的 Python 社区提供的支持。
您希望在您担任董事会成员期间完成什么？
任何开源项目持续面临的挑战之一是让人们参与维护项目的支持基础设施，而不仅仅是从事项目本身。这类工作在定义社区的“用户体验”方面发挥着重要作用，但也常常被低估且令人乏味，因此很难让志愿者对此充满热情。我认为 PSF 有机会为核心开发社区改善这方面的体验做出贡献，尽管（与许多事情一样）存在各种实际考虑因素，使得说起来容易做起来难。
更广泛地说，我真的对转向开放会员模式感到兴奋，并乐于帮助将这些变化付诸实践。长期以来，PSF 一直在努力调和组织本身相对封闭的会员模式与更广泛的 Python 社区中新兴的对开放性和多样性的承诺之间的不匹配，而这些变化意味着基金会的结构现在更好地反映了社区的理想。凭借来自四个国家（澳大利亚、印度、德国和美国）的董事会成员，我们也处于有利地位，可以开始在全球 Python 社区的各个部分之间建立更牢固的联系。
是什么让 Python 成为如此特别和重要的项目和社区？
对我而言，Python 最令人着迷的地方在于它竞争领域的广泛性。在我参与的波音公司项目中，Python 成为我们用于使复杂系统的不同部分协同工作的“首选”粘合语言，以及用于编写测试环境的模拟工具。Linux 发行版也倾向于以类似的方式使用它。在科学领域，它与 MATLAB 等软件在数值计算方面正面竞争，并与 R 在统计分析方面竞争。它是 YouTube 的原始实现语言，也是 OpenStack 组件的首选语言，但仍然足够简单，可以被选为 Raspberry Pi 和 One Laptop Per Child 教育计划的首选编程语言。凭借 Maya 和 Blender 等软件将其用作嵌入式脚本引擎，动画工作室喜欢它，因为动画师可以学习处理以前必须由工作室开发团队处理的任务。
用例的多样性有时会使事情变得复杂，尤其是在核心开发中，竞争利益经常会发生冲突，但这也是一个巨大的优势。
Python 面临的最大直接挑战是什么？
管理 OpenStack 庞然大物对核心开发团队的影响是一个巨大的挑战。目前，我们有大量的企业资金涌入 Linux 内核和 OpenStack，但几乎没有资金投入到提供它们之间链接的 CPython 运行时中。然而，这个特殊的挑战也是一个巨大的机遇，因为即使将一小部分投入 OpenStack 的资源用于全职贡献 CPython，也可能在不断增加的未解决错误报告和 bugs.python.org 上的增强请求方面取得重大进展。
我们也在跨平台依赖管理领域追赶，因为 Python 最初的软件分发工具诞生于“开源”和“使用 Linux”几乎是同义词的时代。为了满足在开源和广泛的互联网访问环境中成长起来的一代人的期望，对基础设施进行现代化改造并非易事，但这也是必不可少的，因为大多数简单的语言级可用性改进已经完成，我们需要让 Python 用户更容易访问 Python 生态系统中除了 CPython、标准库和 python.org 之外的许多高质量工具。
与此相关的是，更广泛的 Python 生态系统的可发现性总体上是一个重要问题。与通常专注于特定问题领域或赞助组织的新型、更集中的语言社区不同，Python 已经足够古老，可以发展成为一个松散、分散的蔓延，为用户提供各种强大的选项。然而，仅仅在 python.org 上的某个地方列出人们可能感兴趣的所有内容并不简单——当用户对在它们之间做出明智选择的了解不足时，这很容易让用户感到选择过多。
我们如何引导对缺乏静态类型感到遗憾的用户使用 pylint 等分析工具，这些工具同样可以帮助检测代码中的结构缺陷？我们如何引导寻求更快代码执行速度的人们使用 PyPy 或 Numba 进行 JIT 编译，或者使用 Cython 进行提前编译？我们如何引导新手 Web 开发人员使用 Django 等全包式框架，同时指出 Flask 和 Pyramid 等更灵活的框架作为经验更丰富的开发人员可能希望探索的替代方案？我们如何在不让开发者感到选择过多的情况下，突出显示开发者可能希望考虑的许多优秀的集成开发环境？这甚至还没有涉及到科学方面的内容，或者 IPython 和 IPython notebook 相对于使用 CPython 运行时提供的极简默认环境的优点。
管理 Python 2 的长期支持承诺（这是 Python 3 过渡的一部分）也排在相当靠前的位置。长期维护是开源世界中最令人厌倦的任务之一，而且，在四年时间里，为 Python 2.7 提供的支持对于几乎完全是志愿者的开发工作来说已经非常出色了。我认为我们实际上有一个很好的先例来解决这个问题，即 Linux 领域中长期支持内核的处理方式：商业再发行商在上游协作，以最大限度地减少重复彼此工作的需要。我们在这方面已经取得了一些成功，微软的 Visual Studio 团队现在贡献了开发人员时间来处理 Windows 二进制安装程序的创建，我们将继续向下游再发行商指出，向上游 Python 2.7 分支提供的志愿者补丁的速度已经放缓，因此他们可能需要在上游维护方面进行更多投资，以继续履行其自身的客户支持义务。
我们对 Python 基金会以及 Python 编程语言的未来有何期待？
从基金会方面来看，目标是提高基金会活动的透明度，并增加基金会本身的参与度。长期以来，社区的许多成员一直将基金会视为一个外部实体，只为少数幸运地收到邀请参与的精英而存在，甚至那些已经被邀请的成员也经常会问“好吧，我现在是会员了，有什么不同吗？”并且没有得到特别明确的答案。随着向开放会员模式的过渡，我希望看到基金会发展壮大，达到一个由社区运营、为社区服务、参与向任何有兴趣参与的人开放的程度。
对于编程语言，我偶尔会说的一句话是，Python 打包机构目前对 Python 未来的影响比 python-dev 本身更大。我这样说的原因是 python-dev 的许多重要工作都在以年为单位的时间尺度上进行；当我们添加新功能来解决我们今天遇到的问题时，我们知道通常需要两、三、四甚至更长时间才能依靠它们始终可用。
相比之下，Python 打包机构大约每六个月发布一个新版本的 pip，而 pip 是我们选择的工具，用于使 Python 包索引上的各种 Python 软件更易于所有 Python 用户使用。与许多特定于语言的打包工具（这些工具通常似乎专注于软件即服务用例，而排除所有其他用例）不同，我们在设计整个系统时，试图明确考虑系统集成商和 Python 再发行商的需求。部分原因是出于向后兼容性的考虑，但另一个关键方面是降低 Python 生态系统的其余部分进入 CPython 本身享有的许多不同再发行渠道的门槛。
如果我们成功实现我们的目标，那么将几乎任何 PyPI 包自动转换为符合策略的下游包将成为可能，并且在那些无法转换的情况下，该工具应支持适当地调整安装过程，而无需复制来自上游包的现有元数据。
话虽如此，语言和 CPython 运行时本身仍在发生一些令人兴奋的变化。对于 Web 和网络编程社区，Python 3.4 中添加的 asyncio 模块最终为 Python 标准库带来了成熟的异步 IO 功能。对安全性的日益关注以及对底层操作系统功能的更好访问带来了对隔离模式（其中 Python 3 忽略几乎所有环境设置）的支持、对 openat 和其他基于目录描述符的命令的支持、改进的哈希算法、对操作系统 SSL 证书存储的访问、各种其他 SSL 改进以及 multiprocessing 模块的更多可配置行为，包括完全避免使用 fork 系统调用的能力。
调试支持得到了很大改进，标准库中引入了枚举，使套接字模块常量更具自文档性，增强了对 C 扩展模块和内置函数的内省支持，以及在分段错误和跟踪内存分配时打印回溯的功能。由于标准库中包含了 pathlib、statistics 和 ipaddress 模块，常见的编程操作现在变得更加简单。围绕对象和解释器清理的各种长期存在的问题也得到了解决。
展望未来，迄今为止 Python 3.5 的一项已确认的更改意味着 Python 将获得一个专用的矩阵乘法中缀运算符，这是科学 Python 社区十多年来讨论他们改进科学和数学代码可读性的需求的结晶。未来一年还将看到 Ubuntu 和 Fedora 等主要 Linux 发行版继续向仅在其安装介质中包含 Python 3 的方向迁移，这可能会导致 Python 3 在 Linux 系统上与操作系统边界交互的方式进行一些调整。
1 条评论