SciPy 1.12 中文文档（六十八）

最新推荐文章于 2024-06-30 10:47:26 发布

绝不原创的飞龙

最新推荐文章于 2024-06-30 10:47:26 发布

阅读量1.4k

点赞数 9

分类专栏： scipy 文章标签： scipy

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

本文链接：https://blog.csdn.net/wizardforcel/article/details/140061607

版权

scipy 专栏收录该内容

81 篇文章 2 订阅

订阅专栏

原文：docs.scipy.org/doc/scipy-1.12.0/index.html

贡献方式

原文：docs.scipy.org/doc/scipy-1.12.0/dev/hacking.html

本文旨在概述向 SciPy 贡献的方式。它试图回答常见问题并提供一些关于社区实际工作流程的见解。熟悉 SciPy 社区并且是有经验的 Python 编码者的读者可能希望直接跳转到 SciPy 贡献者指南。

有很多方式可以贡献：

贡献新代码
修复错误，改进文档，以及其他维护工作
审查开放的拉取请求
问题分类
在 scipy.org 网站上工作
回答问题并参与 scipy-dev 和 scipy-user 的邮件列表。

贡献新代码

如果你已经使用科学 Python 工具栈一段时间，可能会有一些代码堆积，你会觉得“这对其他人也可能有用”。也许将其贡献给 SciPy 或其他开源项目是个不错的主意。首先要问的问题是，这些代码应该放在哪里？这个问题在这里很难回答，所以我们从更具体的问题开始：哪些代码适合放入 SciPy？ 添加到 SciPy 的几乎所有新代码都具有一个共同点，那就是它在多个科学领域中有潜在的用途，并且它适合于现有 SciPy 子包的范围内（参见决定新功能）。原则上，也可以添加新的子包，但这种情况较少见。对于特定于单一应用程序的代码，可能已经存在可以使用该代码的现有项目。一些 SciKits（例如scikit-learn、scikit-image、statsmodels等）在这里是很好的例子；它们的焦点更窄，因此比 SciPy 具有更多领域特定的代码。

现在，如果你有想要包含在 SciPy 中的代码，你应该怎么做呢？在确认你的代码可以在兼容的许可下分发给 SciPy 之前（参见许可考虑），第一步是在 scipy-dev 邮件列表上讨论。所有新功能以及对现有代码的更改都在那里讨论和决定。你可以在你的代码完成之前开始这个讨论。请记住，为了添加到 SciPy 中，你的代码需要被其他人审查，因此尽量找到愿意审查你工作的人。

假设邮件列表上的讨论结果是积极的，并且你有一个能做你需要的事情的函数或代码片段，接下来呢？在代码添加到 SciPy 之前，它至少需要有良好的文档、单元测试、基准测试以及正确的代码风格。

单元测试

原则上，你应该创建能够测试你添加的所有代码的单元测试。这样可以在一定程度上确保你的代码在不同 Python 版本和你自己无法获得的硬件或操作系统上也能正确运行。如何撰写单元测试的详细描述可以在测试指南中找到，而本地运行 SciPy 测试则说明了如何运行这些测试。
基准测试

单元测试检查正确功能；基准测试衡量代码性能。并非所有现有的 SciPy 代码都有基准测试，但应该有：随着 SciPy 的发展，监控执行时间以捕获意外的性能回归变得越来越重要。有关如何撰写和运行基准测试的更多信息可以在 Benchmarking SciPy with airspeed velocity 中找到。
文档

清晰完整的文档对于用户能够查找和理解代码至关重要。单个函数和类的文档，包括至少基本描述、所有参数和返回值的类型和含义，以及doctest格式的使用示例，都放在文档字符串中。这些文档字符串可以在解释器中阅读，并编译成 HTML 和 pdf 格式的参考指南。关于如何撰写文档的指南可以在文档风格中找到，而使用 Sphinx 本地渲染文档则解释了如何预览文档，看起来就像在线一样。
代码风格

统一的代码风格可以让其他人更容易阅读你的代码。SciPy 遵循标准的 Python 风格指南，PEP8，唯一的例外是推荐的最大行长度为 88 个字符，而不是 PEP8 的 79 个字符。

我们提供一个 git 预提交钩子，可以检查每个提交的风格是否正确。通过以下命令在 SciPy 存储库的根目录安装它（一次性）：
```
cp tools/pre-commit-hook.py .git/hooks/pre-commit 
```
或者，您也可以手动运行代码检查工具：
```
python dev.py lint 
```
大多数集成开发环境（IDE）和文本编辑器都有设置，可以帮助你遵循 PEP8，例如将制表符转换为四个空格。更多信息可以在 PEP8 和 SciPy 中找到。

一个检查清单，包括这些和其他要求，可以在示例的末尾开发工作流程中找到。

您可能还有另一个问题：我应该把我的代码放在哪里？要回答这个问题，了解 SciPy 的公共 API（应用程序编程接口）的定义是很有用的。对于大多数模块来说，API 是两层深度的，这意味着您的新函数应该出现为 scipy.subpackage.my_new_func。my_new_func 可以放在 /scipy/<subpackage>/ 下的现有或新文件中，其名称应添加到该文件中的 __all__ 列表中（该列表列出文件中的所有公共函数），然后在 /scipy/<subpackage>/__init__.py 中导入这些公共函数。任何私有函数/类的名称应该以下划线（_）开头。SciPy 的公共 API 的更详细描述在 SciPy API 中给出。

一旦您认为您的代码准备好包含在 SciPy 中，您可以在 Github 上发送一个拉取请求（PR）。我们不会在这里详细讨论如何使用 git，这在 Git for development 和 Github 帮助页面中有很好的描述。当您为一个新功能发送 PR 时，请确保在 scipy-dev 邮件列表上也提及此事。这可以促使感兴趣的人帮助审查您的 PR。假设您之前已经得到了关于您的代码/功能的总体想法的积极反馈，那么代码审查的目的是确保代码正确、高效并符合上述要求。在许多情况下，代码审查会相对快速完成，但也可能会停滞。如果您已经处理了所有已给反馈，那么在一定合理的时间（比如几周）之后，再次在邮件列表上请求审查是完全可以的。一旦审查完成，PR 就会合并到 SciPy 的“main”分支中。

上述描述了向 SciPy 添加代码的要求和过程。但它并没有准确回答决策是如何做出的问题。基本答案是：决策是通过共识达成的，由所有选择参与邮件列表讨论的人员决定。这包括开发人员、其他用户和你自己。在讨论中追求共识非常重要——SciPy 是科学 Python 社区的一个项目。在那些罕见的情况下，无法达成一致意见时，相关模块的维护者可以决定问题的解决方式。

许可证考虑

我基于我在网上找到的现有 Matlab/R/… 代码编写了我的代码，这样可以吗？

这取决于情况。SciPy 使用 BSD 许可证分发，因此如果您的代码基于的代码也是 BSD 许可证或具有 BSD 兼容许可证（例如 MIT、PSF），那么可以接受。如果代码是 GPL 或 Apache 许可证，没有明确的许可证，需要引用或仅适用于学术使用，则无法包含在 SciPy 中。因此，如果您复制了具有此类许可证的现有代码或直接将其翻译为 Python，则您的代码无法包含在内。如果您不确定，请在 scipy-dev 的邮件列表上咨询。

SciPy 为何采用 BSD 许可证而不是 GPL？

与 Python 一样，SciPy 使用“宽松”的开源许可证，允许专有重用。尽管如此，这使得公司可以在不返回任何东西的情况下使用和修改软件，但人们认为更大的用户基础会带来更多的贡献，公司通常也会发布它们的修改，而无需强制要求。请参阅约翰·亨特的BSD 提案。

有关 SciPy 许可证的更多信息，请参阅 Licensing。

维护现有代码

前面的部分特别讨论了向 SciPy 添加新功能。讨论的很大一部分也适用于现有代码的维护。维护意味着修复错误，提高代码质量，更好地记录现有功能，添加缺失的单元测试，添加性能基准，保持构建脚本的更新等等。SciPy 的问题列表包含了所有报告的错误，构建/文档问题等。修复问题有助于提高 SciPy 的整体质量，并且也是熟悉项目的好方法。您可能还想修复一个错误，因为您遇到了这个问题，并且需要相关函数正常工作。

上述关于代码风格和单元测试的讨论同样适用于 bug 修复。通常最好先编写一个显示问题的单元测试，即该测试应该通过但实际未通过。一旦完成，您可以修复代码以使该测试通过。这应该足以为此问题发送一个 PR。与添加新代码时不同，可能不需要在邮件列表上讨论此问题 - 如果代码的旧行为显然是不正确的，那么没有人会反对将其修复。可能需要为更改后的行为添加一些警告或弃用消息。这应该是审查过程的一部分。

注意

不鼓励仅更改代码风格的拉取请求，例如修复文件中的一些 PEP8 问题。这些 PR 通常不值得在 git annotate 历史中堆砌，而且会占用审阅者的时间，这些时间可能更好地用在其他方面。但是，如果作为功能更改的一部分触及的代码进行了代码风格清理，则是可以接受的。

审查拉取请求

审查开放的拉取请求（PR）非常受欢迎，也是帮助项目前进速度的宝贵方式。如果您在特定领域具有特定的知识/经验（例如“优化算法”或“特殊函数”），那么审查该领域的 PR 尤为重要 - 有时具有技术代码的 PR 由于缺乏适当的审阅者而需要等待很长时间才能合并。

我们鼓励每个人参与审查过程；这也是熟悉代码库的好方法。审稿人应自问以下问题中的一些或全部：

此更改是否充分讨论（适用于新功能和更改现有行为）？
功能在科学上是否合理？算法可能基于文献已知工作；否则，对正确性的更近一步检查是宝贵的。
在所有情况下，预期行为是否清晰（例如，如空数组或 nan/inf 值等意外输入）？
代码是否符合贡献新代码部分概述的质量、测试和文档期望？

如果我们还不认识您，请考虑介绍自己。

其他贡献方式

除编写代码外，还有许多贡献方式。

故障排除问题（验证错误报告的有效性和可能的行动）也是一种有用的活动。SciPy 有数百个开放问题；关闭无效问题并正确标记有效问题（最好在评论中提出一些初步想法）允许优先处理维护工作，并在处理现有功能或子包时轻松找到相关问题。有关问题排查的更多信息，请阅读故障排查和问题管理。

参与 scipy-user 和 scipy-dev 邮件列表的讨论本身就是一种贡献。每个写信的人都希望得到回应，编写这些回应使项目和社区运行得更好，也更具欢迎性。

scipy.org 网站包含关于 SciPy 项目和 SciPy 社区的大量信息，而且它总是需要新的帮手。网站的源代码存放在自己的单独存储库中：github.com/scipy/scipy.org

开始

感谢您对贡献 SciPy 的兴趣！如果您有兴趣贡献代码，希望您继续阅读 SciPy 贡献者指南，了解如何设置开发环境、实现改进并提交首个 PR 的详细信息！

贡献者快速入门指南

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/dev_quickstart.html

在从 GitHub 获取源代码之后，有三个步骤可以开始贡献：

设置开发环境

使用 mamba 或其他多种虚拟环境管理工具的一种，可以确保 SciPy 的开发版本不会干扰到你机器上的任何其他本地安装的 SciPy。
构建 SciPy

SciPy 使用编译代码来提高速度，这意味着根据你的系统可能需要额外的依赖项才能完成此步骤 - 参见从源码构建。
执行开发任务

这些可以包括你想要对源代码进行的任何更改、运行测试、构建文档、运行基准测试等。

基本工作流程

注意

我们强烈建议使用用户激活的环境设置，例如 conda 或虚拟环境。

由于 SciPy 包含了用 C、C++ 和 Fortran 编写的部分内容，需要在使用之前进行编译，请确保已安装必要的编译器和 Python 开发头文件。如果你使用的是 mamba，这些将会自动安装。如果你使用 pip，请检查可能需要的系统级依赖。

首先，在 GitHub 上将主要 SciPy 仓库的副本分叉到你自己的账户中，然后通过以下方式创建你的本地仓库：

git clone git@github.com:YOURUSERNAME/scipy.git scipy
cd scipy
git submodule update --init
git remote add upstream https://github.com/scipy/scipy.git

接下来，设置你的开发环境。在系统级依赖 已安装 的情况下，从你的 SciPy 克隆的基本目录中的终端执行以下命令：

# Create an environment with all development dependencies
mamba  env  create  -f  environment.yml  # works with `conda` too
# Activate the environment
mamba  activate  scipy-dev

# Create the virtual environment
python  -m  venv  $HOME/.venvs/scipy-dev
# Activate the environment
source  $HOME/.venvs/scipy-dev/bin/activate
# Install python-level dependencies
python  -m  pip  install  numpy  pytest  cython  pythran  pybind11  meson  ninja  pydevtool  rich-click  hypothesis

你的命令提示现在显示你的新环境名称，如 (scipy-dev)$。

最后，为了开发 SciPy 并运行测试套件，请执行以下操作：

python dev.py test  # this will always (re)build as needed first

请注意这将需要几分钟时间（默认情况下禁用了一些非常慢的测试），因此你可能只想测试你将要处理的 SciPy 的部分。有关如何执行此操作的详细信息，请参阅开发工作流程中的更完整设置步骤，或者 python dev.py test --help。

其他工作流程

这只是设定开发环境的一种可能方式，具体指令请参见 SciPy 贡献者指南。

注意

如果你在从源码构建 SciPy 或设置本地开发环境时遇到问题，可以尝试使用 GitHub Codespaces 构建 SciPy。它允许你在浏览器中创建正确的开发环境，减少了安装本地开发环境和处理不兼容依赖项的需求。

如果您有良好的互联网连接并且想要临时设置，通常更快的方法是在 Codespaces 环境中工作。有关如何开始使用 Codespaces 的文档，请参阅Codespaces 文档。在为 scipy/scipy 存储库创建 codespace 时，默认的 2 核机型可用；4 核会稍快地构建和工作（但当然会减少您的免费使用小时数）。一旦您的 codespace 启动，您可以运行 conda activate scipy-dev，您的开发环境就完全设置好了 - 然后您可以按照 SciPy 文档的相关部分来构建、测试、开发、撰写文档并向 SciPy 贡献。

另一种选择是使用Gitpod。我们不再维护这个解决方案，但一些信息可以在我们文档的旧版本中找到。

开发工作流程

原文：docs.scipy.org/doc/scipy-1.12.0/dev/contributor/development_workflow.html

注：在阅读或之后，考虑观看 SciPy 开发工作流程 的示例，以修复 bug 并提交拉取请求。

本指南假定你已经创建了自己的 SciPy 仓库分支（副本），在你自己的机器上克隆了仓库，并从这个源代码构建了 SciPy。如果没有，请查看适合你系统的从源码构建页面。在开始之前，还有两件事你需要做一次：

在终端中，向 Git 介绍你自己：
```
git config --global user.email you@yourdomain.com
git config --global user.name "Your Name" 
```
这些信息为你的工作贡献提供了认可，但请注意，如果你“推送”你的工作到 GitHub，这些信息将会变成公开可见。更多信息请参见设置你的 Git 提交邮箱地址。
导航到你本地 SciPy 仓库的根目录，并输入：
```
git remote add upstream https://github.com/scipy/scipy.git 
```
这将把名字 upstream 关联到位于 github.com/scipy/scipy.git 的官方 SciPy 仓库。请注意，当你克隆 SciPy 仓库的分支时，Git 已经将名字 origin 关联到你的分支上。你需要这两个 “远程” 的原因是，你通常会从官方仓库 upstream 开始，做出改动，然后把你的改动“推送”到你的分支 origin，然后提交一个“拉取请求”请求 SciPy 把你的改动从你的分支合并到官方仓库。
初始化 git 子模块：
```
git submodule update --init 
```
这将获取并更新 SciPy 所需的任何子模块（如 Boost）。

基本工作流程

简而言之：

每次编辑时，请为每组编辑启动一个功能分支。参见下文。
开始吧！参见下文。
完成后：
- 贡献者：将你的功能分支推送到你自己的 Github 仓库，并创建一个拉取请求。
- 核心开发者 如果你想在无需进一步审核的情况下推送更改，请参阅下文这里的注意事项。

这种工作方式有助于保持工作有序，并尽可能清晰地记录历史。

参见

有许多在线教程可以帮助你学习 git。关于特定 git 工作流的讨论，请参阅这些讨论：linux git workflow，以及 ipython git workflow。

制作一个新的功能分支

首先，在终端中导航到 SciPy 根目录，并从upstream存储库获取新的提交：

git fetch upstream

接下来，在上游存储库的主分支基础上创建一个新分支：

git checkout -b my-new-feature upstream/main

或者，您可能希望保持自己仓库的主分支更新，并基于此创建一个新分支：

git checkout main
git rebase upstream/main
git checkout -b my-new-feature

按顺序执行以下命令

确保您的本地仓库当前检出了main分支，
将所有最新的更改从upstream/main（SciPy 仓库的主分支）应用到您的本地main分支，并
创建并检出一个基于您本地main分支的新分支（使用 -b）。

无论如何，确保您的功能分支包含来自上游主分支的最新更改，以帮助避免提交拉取请求时的合并冲突。

在继续之前，建议先构建并运行测试这个分支。假设您已经按照其中一个从源代码构建页面设置好了开发环境，您需要激活开发环境，然后运行测试（请注意，如果需要，dev.py test 命令将自动执行构建）：

conda activate scipy-dev
python dev.py test -v 
```### 编辑工作流程

#### 概述

```py
# hack hack
git status # Optional
git diff # Optional
git add modified_file
git commit
# push the branch to your own Github repo
git push origin my-new-feature

更详细地说，

进行一些更改。当您感觉已经完成了一个完整的、可工作的相关更改集时，继续下一步骤。

可选步骤：使用 git status 检查更改的文件（参见 git status）。您会看到如下列表：

# On branch my-new-feature
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#  modified:   README
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#  INSTALL
no changes added to commit (use "git add" and/or "git commit -a")

可选步骤：使用 git diff 比较与上一个版本的更改（参见 git diff）。这将打开一个简单的文本浏览器界面，突出显示您的文件与上一个版本之间的差异。
使用 git add modified_file 添加任何相关修改或新文件（参见 git add）。这将把文件放入暂存区，即将添加到您的下一个提交的文件队列中。仅添加具有相关、完整更改的文件。将带有未完成更改的文件留到稍后提交。
要将暂存的文件提交到本地仓库的副本中，请运行 git commit。此时，将会打开一个文本编辑器，允许您编写提交消息。请阅读提交消息部分，确保您编写了格式正确且足够详细的提交消息。保存消息并关闭编辑器后，您的提交将被保存。对于简单的提交，可以使用 -m 标志通过命令行传递简短的提交消息。例如，git commit -am "ENH: Some message"。

在某些情况下，你会看到这种形式的提交命令：git commit -a。额外的 -a 标志会自动提交所有修改的文件并移除所有删除的文件。这可以节省你键入大量 git add 命令的时间；但是，如果不小心，它可能会向提交添加不必要的更改。欲了解更多信息，请参见为什么使用 -a 标志？ - 以及在 tangled working copy problem 中的有用用例描述。
将更改推送到您在 github 上分叉的仓库：
```
git push origin my-new-feature 
```
欲了解更多信息，请参见 git push。

注意

假设你已经按照这些页面的说明操作，git 将会为你的 github 仓库创建一个名为 origin 的默认链接。在 git >= 1.7 中，你可以通过使用 --set-upstream 选项来永久设置到 origin 的链接：

git push --set-upstream origin my-new-feature

从现在开始，git 将会知道 my-new-feature 与你自己的github 仓库中的 my-new-feature 分支相关联。随后的推送调用将简化为以下内容：

git push

对于每个新分支的创建，你必须使用--set-upstream。

可能在您编辑时，已经有新的提交添加到 upstream，这些提交可能会影响到您的工作。在这种情况下，按照在主分支上重新基础的说明将这些更改应用到您的分支上。

撰写提交信息

提交信息应当清晰，并遵循几个基本规则。例如：

ENH: add functionality X to SciPy.<submodule>.

The first line of the commit message starts with a capitalized acronym
(options listed below) indicating what type of commit this is. Then a blank
line, then more text if needed.  Lines shouldn't be longer than 72
characters.  If the commit is related to a ticket, indicate that with
"See #3456", "See ticket 3456", "Closes #3456", or similar.

描述变更的动机，修复 bug 的性质或者增强功能的细节都是值得在提交信息中包含的。提交信息应该在不查看代码变更的情况下也能够理解。像 MAINT: fixed another one 这样的提交信息就是不好的例子；读者必须去寻找其他上下文来理解。

提交信息的标准首字母缩写包括：

API: an (incompatible) API change
BENCH: changes to the benchmark suite
BLD: change related to building SciPy
BUG: bug fix
DEP: deprecate something, or remove a deprecated object
DEV: development tool or utility
DOC: documentation
ENH: enhancement
MAINT: maintenance commit (refactoring, typos, etc.)
REV: revert an earlier commit
STY: style fix (whitespace, PEP8)
TST: addition or modification of tests
REL: related to releasing SciPy

注意

你可以添加一些标记来跳过连续集成的部分。参见连续集成。#### 请求将您的更改与主仓库合并

当你觉得你的工作完成时，你可以创建一个拉取请求（PR）。Github 有一个很好的帮助页面介绍了如何提交拉取请求。

如果您的更改涉及对 API 的修改或者函数的添加/修改，您应该启动一次代码审查。这包括向 SciPy 邮件列表发送一封带有您 PR 链接以及变更描述和动机的电子邮件。#### 提交 PR 之前的检查清单

您确认代码可以根据 BSD 许可证分发吗？请参阅许可证考虑。
是否有良好代码覆盖率的单元测试？请参阅NumPy/SciPy 测试指南。
所有单元测试在本地都通过了吗？请参阅从源代码构建 SciPy 开发。
所有公共函数都有文档字符串，包括示例吗？请参阅numpydoc 文档字符串指南。
文档是否正确渲染？请参阅使用 Sphinx 在本地渲染文档。
代码风格是否正确？请参阅 PEP8 和 SciPy。
是否有基准测试？请参阅使用 airspeed velocity 对 SciPy 进行基准测试。
提交消息格式是否正确？请参阅正确格式化的提交消息？
新功能的文档字符串是否标记为.. versionadded:: X.Y.Z（其中X.Y.Z是下一个版本的版本号）？例如，请参阅differential_evolution的updating、workers和constraints文档。
如果有较大的新增内容，是否有教程或更详细的模块级描述？教程文件在doc/source/tutorial中。
如果新增文件，它们是否通过meson.build正确集成？有关更多信息，请参阅编译代码。

SciPy 贡献者指南

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/contributor/contributor_toc.html

本指南旨在帮助您在查看了《贡献方式》[…/hacking.html#hacking]或《贡献者快速入门指南》[…/dev_quickstart.html#dev-quickstart]的入门材料后，快速找到关于 SciPy 开发的信息。

您还可以观看SciPy 开发工作流程，这是一个修复错误并提交 Pull 请求的五分钟视频示例（注意：此视频来自 2018 年，因此构建步骤现在已有所不同，但总体工作流程仍然相同）。

从源代码构建 - 如何设置开发环境，包括安装编译器和 SciPy 依赖项，在 GitHub 上克隆 SciPy 存储库并更新 git 子模块，并使用dev.py接口进行构建和运行测试。
编辑 SciPy - 如何编辑 SciPy Python 代码，包括查找包含 SciPy 功能的模块、向 SciPy 添加新模块以及符合 PEP8 样式标准的技巧
单元测试 - 如何使用 pytest 框架编写和运行 SciPy 的单元测试
文档 - 如何编写符合 docstring 标准的 reStructuredText 文档，本地使用 Sphinx 构建文档，并查看在持续集成检查期间构建的文档
基准测试 - 如何使用 airspeed velocity 对代码进行基准测试
编译代码 - 如何将快速编译的代码添加到 SciPy
持续集成 - 我们的持续集成系统是如何工作的以及如何调试您的 PR

编辑 SciPy

开发工作流程描述了在设置完开发环境后应该做什么
PEP8 和 SciPy 提供了确保您的代码符合 PEP8 规范的一些技巧
用于开发的 Git 是使用git的指南，这是一个分布式版本控制系统，用于管理来自世界各地对 SciPy 代码所做的更改
SciPy API 包含了关于 SciPy 代码组织方式的重要注释，并记录了 SciPy API 的结构；如果您打算导入其他 SciPy 代码，请先阅读本文。
审查 Pull 请求解释了如何在本地审查其他作者的 SciPy 代码
问题分类和策划解释了如何策划问题和 PR，并介绍了 SciPy 的 GitHub 团队权限工作方式
添加新方法、函数和类包含了如何添加新方法、函数和类的信息
SciPy 核心开发者指南包括背景信息，包括如何做出决策和准备发布；面向核心开发者，但对所有贡献者都包含有用信息
代码和文档风格指南 - 缺失的部分 - 代码和文档风格指南 ## 单元测试
测试指南是撰写 NumPy 或 SciPy 代码单元测试的权威指南（NumPy 文档的一部分）
在本地运行 SciPy 测试记录了构建 SciPy 并在本地运行测试的命令 dev.py test ## 文档
文档风格包含了撰写文档字符串的一切知识，这些文档字符串通过Sphinx渲染为 HTML 文档（NumPy 文档的一部分）
为 SciPy 文档做贡献包含有关如何为 SciPy 文档做出贡献的信息
在本地使用 Sphinx 渲染文档在合并 PR 前检查文档如何渲染是非常重要的；本文档解释了您可以如何做到这一点 ## 基准测试
使用 airspeed velocity 对 SciPy 进行基准测试解释了如何使用airspeed velocity为 SciPy 添加基准测试 ## 编译代码
向 SciPy 添加 Cython 使用Cython扩展和编译 Python 代码可以显著提高其性能；本文档帮助您入门
超越 Python 讨论了在 SciPy 中使用 C、C++ 和 Fortran 代码的情况
公共 Cython API 关于公开 Cython API 的指导方针

ROADMAP

SciPy 路线图

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/roadmap.html

此路线图页面仅包含 SciPy 未来发展的最重要想法和需求。更详细的路线图，包括每个子包的状态、更多的想法、API 稳定性等，请参见详细的 SciPy 路线图。

支持分布式数组和 GPU 数组

NumPy 已经通过__array_function__和__array_ufunc__将其 API 与执行引擎分离。这将使得 SciPy 的部分接受分布式数组（例如dask.array.Array）和 GPU 数组（例如cupy.ndarray），这些数组实现了ndarray接口。目前还不清楚哪些算法可以直接使用，以及它们是否在使用时能够获得显著的性能提升。我们希望创建一个 SciPy API 的映射，并随着时间的推移改进支持。

除了利用 NumPy 的协议如__array_function__，我们还可以在 SciPy 中使用这些协议。这将使得可以（重新）实现 SciPy 函数，例如在 Dask 或 GPU 数组中的scipy.signal函数（参见NEP 18 - use outside of NumPy）。NumPy 在这些领域的功能仍在不断发展中，例如参见NEP 37 - A dispatch protocol for NumPy-like modules，而 SciPy 对于这些功能是一个重要的“客户”。

性能改进

加速算法的速度改进，减少内存使用和能够并行化算法对大多数科学领域和使用案例都有益处。我们已经为多进程设计了一个 API 设计模式 - 使用workers关键字 - 可以在更多的函数中采用。

通过像 Pythran 这样的加速器启用，可能通过 Transonic 实现，并使用户能够更轻松地在依赖于 SciPy 功能的代码中使用 Numba 的@njit，这将带来大量的性能提升。不过，这需要一个策略，所有的解决方案仍在成熟中（参见例如此概览）。

最后，许多单独的函数可以针对性能进行优化。尤其是在scipy.optimize和scipy.interpolate函数方面经常被请求进行优化。

统计增强

对于scipy.stats中的增强功能以及详细的 SciPy 路线图中列出的内容，对项目特别重要。

对一元分布基础设施进行全面改进，以解决长期存在的问题（例如参见gh-15928）。
在stats函数中一致处理nan_policy、axis参数和掩码数组（适当的情况下）。

支持更多的硬件平台

现在，SciPy 已经为 ARM64（或aarch64）和 POWER8/9（或ppc64le）进行了持续集成，并且可以通过Miniforge获得二进制文件。这些平台上的 PyPI 轮子现在也是可能的（符合manylinux2014标准），对这些轮子的请求也越来越多。

此外，现在可以在 TravisCI 上进行 IBM Z（或s390x）的持续集成，但尚未完成 - 并且那个平台上的manylinux2014轮子也可能。最后，解决 AIX 构建问题会帮助用户。

实现稀疏数组，除了稀疏矩阵外。

稀疏矩阵格式大部分功能已完善，但主要问题在于它们的行为类似于numpy.matrix（在某个时候将在 NumPy 中废弃）。我们希望的是稀疏数组，它们的行为类似于numpy.ndarray。这正在github.com/pydata/sparse上进行工作，已经相当成熟。初步计划是：

一旦pydata/sparse功能完善（它仍然需要 CSC/CSR 等价物）并且性能足够好，就可以开始依赖它。
在文档中指出，对于新代码，用户应优先考虑使用pydata/sparse而不是稀疏矩阵。
当 NumPy 废弃numpy.matrix时，作为一个独立包进行维护或供应商化。

详细的 SciPy 路线图

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/roadmap-detailed.html

大多数路线图旨在提供关于 SciPy 各子模块在新功能、错误修复等方面最需要的高层次视图。除了重要的“业务常规”更改外，它还包含了一些主要新功能的想法 - 这些被标记为这样，并且预计需要显著的专注力量。在此路线图中未提到的事项未必不重要或超出范围，然而我们（SciPy 开发者）希望向用户和贡献者提供 SciPy 未来发展方向和最需要帮助的清晰图景。

注

这是详细的路线图。只包含最重要的想法的高级概述是 SciPy 路线图。

总体情况

这个路线图将与 SciPy 一起不断更新。更新可以通过提交拉取请求来完成。对于大型或颠覆性的更改，建议您首先在 scipy-dev 邮件列表上讨论。

API 变更

总体上，我们希望尽可能地演进 API 以消除已知的缺陷，尽可能不破坏向后兼容性。

测试覆盖率

最近几年新增代码的测试覆盖率相当不错，我们目标是所有新增代码都具有高覆盖率。然而，仍有大量旧代码的覆盖率较低。将其提升到当前标准可能不现实，但我们应填补最大的漏洞。

除了覆盖率外，还存在正确性问题 - 较旧的代码可能有少量提供良好语句覆盖率的测试，但这并不一定意味着代码是否如箱子上所说的那样运行。因此，对代码的某些部分（特别是 stats、signal 和 ndimage）进行代码审查是必要的。

文档

文档的形式良好。扩展当前的文档字符串 - 添加示例、引用和更好的解释 - 应该继续。大多数模块还在参考指南中有一个很好的入门教程，然而有几个缺失或不完整的教程 - 这些应该被修复。

性能基准

基于 asv 的基准测试系统已经相当完善。添加新的基准测试相当容易，但运行基准测试并不是非常直观。简化这一过程是一个优先事项。

使用 Cython

Cython 用于使用 NumPy 数组的旧语法应移除，并用 Cython 内存视图替换。当 Cython 3.0 发布时，最后使用过时的 NumPy C API 的部分（在 SciPy 中已修复）将消失。然后我们可以无条件地定义 NPY_NO_DEPRECATED_API。

使用 Pythran

Pythran 仍然是可选的构建依赖项，并且可以通过 -Duse-pythran=false 来禁用。目标是将其变为强制性依赖项 - 为此必须清楚维护负担足够低。

使用古老的 Fortran 库

SciPy 的成功很大程度上归因于依赖于包装良好的 Fortran 库（QUADPACK、FITPACK、ODRPACK、ODEPACK 等）。其中一些库老化得很好，另一些则不然。我们应该审查我们对这些库的使用情况，考虑维护工作量、功能性以及（可能的部分）替代方案，包括 SciPy 内部的替代方案。

持续集成

持续集成目前覆盖 32/64 位 Windows、macOS 上的 x86-64/arm、32/64 位 Linux 上的 x86 以及 Linux 上的 aarch64 - 以及我们依赖项的多个版本和构建发布质量的 wheel。最近（2023 上半年），由于支持的配置数量较多，某些 CI 任务需要进行大修，CI 的可靠性不佳。我们的目标是通过在删除 distutils 基础的工作时减少构建时间，并使 CI 任务集更正交来实现这一点。

二进制文件大小

SciPy 的二进制文件相当大（例如，未解压的 manylinux wheel 1.7.3 在 PyPI 上为 39 MB，安装后为 122 MB），这可能会带来问题 - 例如在 AWS Lambda 中使用，该服务有 250 MB 的大小限制。我们的目标是尽可能保持二进制大小的低廉；在添加新的编译扩展时，需要进行检查。在multibuild中去除调试符号可能可以改进（参见此问题）。应该尽可能精简，并且不要添加新的大文件。在未来，正在考虑的可能有助于的事项包括分离打包的libopenblas和移除对long double的支持。

模块

群集

dendrogram 需要重写，有一些难以修复的问题和功能请求。

常量

这个模块基本完成，低维护且没有未解决的问题。

fft

这个模块状态良好。

积分

ODE 求解器需要：

文档非常糟糕，需要修复
SciPy 1.0.0 中添加了新的 ODE 求解器接口（solve_ivp）。未来我们可以考虑（软）弃用旧 API。

数值积分函数状态良好。可以添加对复值函数积分和积分多个区间的支持（参见 gh-3325）。

插值

样条拟合：我们需要具有更好用户控制的样条拟合例程。这包括

用户可选择的平滑标准替代方案（手动、交叉验证等）；gh-16653 在这个方向上有了一些开端；
几种节点放置策略，包括手动和自动（使用 Dierckx、de Boor 算法，可能还有其他算法）。

一旦我们有了功能齐全的集合，我们可以开始审视备受尊敬的 FITPACK Fortran 库的未来，该库目前是在 SciPy 中构建平滑样条的唯一方式。

张量积样条：RegularGridInterpolator 提供了一个最小实现。我们希望在新功能（例如导数）、性能和 API 方面进一步发展，并可能提供一个透明的 N 维张量积 B 样条对象。

可扩展性和性能：对于基于 FITPACK 功能的数据，非 ILP64 构建的数据大小受 32 位 Fortran 整数大小的限制。对于 N-D 散点插值器（基于 QHull）和 N-D 规则网格插值器，我们需要检查大数据集的性能，并在性能不足时进行改进（gh-16483 在这方面取得了进展）。

新功能的想法：可以添加对 NURBS 的支持。

io

wavfile:

PCM 浮点将得到支持，其他情况请使用 audiolab 或其他专业库。
如果数据不被理解，则抛出错误而不是警告。

其他子模块（matlab, netcdf, idl, harwell-boeing, arff, matrix market）状态良好。

linalg

scipy.linalg 状态良好。

需要：

减少与 numpy.linalg 的函数重复，使 API 一致。
get_lapack_funcs 应始终使用 flapack
包装更多 LAPACK 函数
LU 分解功能太多，移除一个

新功能的想法：

在 Cython BLAS 和 LAPACK 中添加类型通用的包装器
将许多线性代数例程转换为通用函数

BLAS 和 LAPACK

Python 和 Cython 接口到 scipy.linalg 中的 BLAS 和 LAPACK 是 SciPy 提供的最重要的内容之一。总体而言，scipy.linalg 状态良好，但我们可以进行一些改进：

库支持。我们发布的轮子现在使用 OpenBLAS，这是目前唯一可行的高性能选项（ATLAS 太慢，MKL 由于许可问题不能成为默认选项，Accelerate 支持已经被移除，因为苹果不再更新 Accelerate）。然而，OpenBLAS 并不十分稳定，有时会因为发布而破坏功能，并且在线程处理方面存在问题（这是使用 PyPy3 时使用 SciPy 的唯一问题）。我们至少需要更好地支持调试 OpenBLAS 的问题，并提供如何用它构建 SciPy 的更好文档。一个选择是使用 BLIS 作为 BLAS 接口（参见 numpy gh-7372）。
支持更新的 LAPACK 功能。在 SciPy 1.2.0 中，我们将 LAPACK 的最低支持版本提高到了 3.4.0。现在我们已经放弃了 Python 2.7，我们可以进一步提高这个版本，并开始添加 LAPACK 中新功能的支持（之前 MKL 和 Python 2.7 是 >3.4.0 的障碍）。

misc

scipy.misc 将被移除作为一个公共模块。其中大部分功能已经被移到另一个子模块或已被弃用。仅剩下的几个功能：

derivative，central_diff_weight：移除，可能用更全面的数值微分功能替换它们。
ascent，face，electrocardiogram：移除或移动到适当的子包（如 scipy.ndimage，scipy.signal）。

ndimage

ndimage底层是一个强大的插值引擎。用户期望两种模型之一：像素模型，其中(1, 1)元素的中心为(0.5, 0.5)；或数据点模型，其中数值在网格上的点上定义。随着时间推移，我们逐渐确信数据点模型更清晰、更易实现，但这应清楚地在文档中进行说明。

更重要的是，SciPy 实现了数据点模型的一种变体，其中轴上任意两个极端处的数据点在周期包装模式下共享空间位置。例如，在 1D 数组中，x[0]和x[-1]位置相同。然而，非常常见的用例是信号周期性，第一个和最后一个元素之间具有相等间距（而非零间距）。针对这种用例，添加了gh-8537中的包装模式，接下来应更新插值例程以使用这些模式。这应该解决几个问题，包括 gh-1323、gh-1903、gh-2045 和 gh-2640。

形态学接口需要标准化：

二进制膨胀/腐蚀/开运算/闭运算需要“结构”参数，而它们的灰度等效操作需要尺寸（必须是元组，而非标量）、脚印或结构。
尺寸应接受标量，等同于在每个轴上提供相同的值。
对于二进制膨胀/腐蚀/开运算/闭运算，结构元素是可选的，而对于灰度操作则是强制性的。灰度形态学操作应采用相同的默认设置。
其他滤波器也应在可能的情况下采用该默认值。

odr

该模块状态良好，尽管可能需要稍作维护。这里没有重大计划或愿望。

optimize

总体而言，该模块状况良好。在 1.2.0 中添加了两个优秀的全局优化器；大规模优化器仍有待填补空白。还需要其他几点：

linprog中的许多额外功能点子（例如整数约束），参见gh-9269。
添加功能到基准套件，以更轻松比较结果（例如通过汇总图表）。
文档中弃用fmin_*函数，优先使用minimize。
scipy.optimize具有广泛的全局优化器准确性和速度基准测试集。这使得我们可以添加新的优化器（如shgo和dual_annealing），其性能显著优于现有优化器。然而，optimize基准系统本身速度较慢且使用不便；我们需要使其更快，并通过绘制性能曲线更容易比较优化器的性能。

signal

卷积和相关性：（相关函数包括 convolve、correlate、fftconvolve、convolve2d、correlate2d 和 sepfir2d。）消除与ndimage（以及其他地方）的重叠。从numpy、scipy.signal和scipy.ndimage（以及其他任何找到的地方），选择 1-D、2-D 和 n-D 卷积和相关性的“最佳类”实现，将其放在某个位置并在整个 SciPy 中一致使用。

B 样条：（相关函数包括 bspline、cubic、quadratic、gauss_spline、cspline1d、qspline1d、cspline2d、qspline2d、cspline1d_eval 和 spline_filter。）将优秀的功能移至interpolate（并进行适当的 API 更改，以匹配interpolate中的操作方式），并消除任何重复。

滤波器设计：合并firwin和firwin2，以便移除firwin2。

连续时间线性系统：移除lsim2、impulse2、step2。lsim、impulse和step函数现在对任何输入系统“一键使用”。进一步提高ltisys的性能（减少不同表示之间的内部转换）。填补 lti 系统转换函数中的空白。

二阶段：使 SOS 滤波与现有方法同等能力。包括 ltisys 对象、lfiltic等效项以及与其他滤波器表示形式的数值稳定转换。对于其数值稳定性，可以将 SOS 滤波器视为 ltisys 对象的默认滤波方法。

小波：目前的内容不太合理。目前仅支持连续小波 - 决定是完全重写还是移除它们。离散小波变换超出范围（PyWavelets 在这方面做得很好）。

稀疏

稀疏矩阵格式基本上已经功能完备，但主要问题在于它们的行为类似于numpy.matrix（在某个时候将在 NumPy 中被弃用）。

我们想要的是行为类似于numpy.ndarray的稀疏数组。在 SciPy 1.8.0中，添加了一组新的类（如csr_array等） - 这些需要在实际应用中进行测试，还需要一些额外功能，如对 1-D 数组的支持。另一个更雄心勃勃的（目前尚不清楚是否会实现）计划正在github.com/pydata/sparse上进行。

一旦pydata/sparse功能完备（仍需 CSC/CSR 等效），并且在性能上达到要求，开始依赖它。
为scipy.sparse.linalg添加对pydata/sparse的支持（之后可能还会添加到scipy.sparse.csgraph）。
在文档中指出，对于新代码，用户应优先选择pydata/sparse而不是稀疏矩阵。
当 NumPy 弃用numpy.matrix时，供应商化或将其作为独立包维护。

关于不同的稀疏矩阵格式：有很多种。这些应该保留，但是应该对 CSR/CSC 进行改进/优化，这是首选格式。LIL 可能是个例外，它本质上效率低下。如果 DOK 被扩展以支持 LIL 目前提供的所有操作，则可以放弃 LIL。

sparse.csgraph

这个模块状况良好。

sparse.linalg

_arpack 和 lobpcg 存在大量的未解决问题。_propack 在 1.8.0 版中是新功能，目前还不清楚其稳定性如何。

_isolve:

callback 关键字不一致
tol 关键字有问题，应该是相对容差
Fortran 代码不可重入（但我们不解决，也许可以从 PyKrilov 重用）

_dsolve:

添加符合许可证的稀疏 Cholesky 或不完全 Cholesky
添加符合许可证的稀疏 QR
改进与 SuiteSparse UMFPACK 的接口
添加与 SuiteSparse CHOLMOD 和 SPQR 的接口

空间

QHull 包装器状态良好，以及 KDTree。

在 C++ 中重写 spatial.distance 度量标准 - 这应该提高性能，使行为更一致（例如对各种非 float64 输入 dtype），并解决数个度量标准的数学定义中仍然存在的一些问题。

特殊

尽管有许多需要提高精度的函数，可能唯一的阻碍因素是超几何函数、抛物线柱函数和球面波函数。处理这个问题的三种可能方式：

获得良好的双精度实现。对于抛物线柱函数（正在进行中）是可行的。我认为对于超几何函数也是可能的，尽管可能时间不够。对于球面波函数，根据当前的理论是不可能的。
将 Boost 的任意精度库移植并在底层使用以获得双精度精度。这可能是超几何函数的临时解决措施；之前 @nmayorov 和 gh-5349 中也提到过使用任意精度的想法。对于球面波函数可能是必要的，这可以重复使用：github.com/radelman/scattering。
在文档中明确警告现有实现的限制。

统计

scipy.stats 子包旨在提供基础统计方法，这些方法可能在标准统计教材中涵盖，例如 Johnson 的 “Miller & Freund’s Probability and Statistics for Engineers”，Sokal & Rohlf 的 “Biometry”，或 Zar 的 “Biostatistical Analysis”。它不旨在复制下游包（例如 StatsModels、LinearModels、PyMC3）的高级功能；相反，它可以为它们构建提供坚实的基础。（请注意，这些是粗略的指导方针，而非严格规则。“高级”是一个模糊且主观的术语，“高级”方法可能也包含在 SciPy 中，特别是如果没有其他广泛使用且得到良好支持的包覆盖该主题。此外，请注意某些与下游项目的重复是不可避免的，而且未必是一件坏事。）

除了 SciPy Roadmap 中描述的项目外，以下改进将有助于 SciPy 更好地发挥其作用。

添加基础和广泛使用的假设检验，例如：
- 后续检验（例如 Dunnett 的检验）
- 各种类型的方差分析（ANOVA）：
  - 双因素方差分析（单次重复，统一次数重复，可变次数重复）
  - 多因素方差分析（即广义的双因素方差分析）
  - 嵌套方差分析
  - 协方差分析（ANCOVA）
另外，为实施假设检验提供基础设施。
为荟萃分析添加额外工具
添加生存分析工具
加快分布的随机变量抽样（方法 rvs），利用适当的 scipy.stats.sampling
扩展 QMC 的功能和性能
加强连续概率分布的 fit 方法：
- 扩展拟合选项以包括：
  - 最大乘积间距
  - L-矩法 / 概率加权矩法
- 在结果中包括拟合优度度量
- 处理被审查数据（例如合并 gh-13699）
实现额外广泛使用的连续和离散概率分布，例如混合分布。
改进 SciPy 提供的核心计算，使其能够稳健地处理广泛范围的参数值。具体而言，将许多来自 Fortran 库 CDFLIB 的 PDF 和 CDF 方法替换为 Boost 实现，如 gh-13328 中所示。

此外，我们应该：

继续努力使 stats 和 stats.mstats 的函数签名更加一致，并添加测试以确保保持一致性。
改进统计检验：返回检验统计量的置信区间，并在计算可行时实现精确的 p 值计算 - 考虑可能的并列情况。

工具链路线图

原文：docs.scipy.org/doc/scipy-1.12.0/dev/toolchain.html

使用 SciPy 库需要（或者可选择依赖于）其他几个库才能正常运行，主要依赖是 Python 和 NumPy。构建该库或构建文档需要更多的库和工具。

当然，工具和库本身并非静态。本文档旨在指导 SciPy 如何随时间推移使用这些动态依赖项。

SciPy 旨在与其依赖库和工具的多个版本兼容。强迫用户基础为每个发布升级到其他组件会大大降低 SciPy 的价值。然而，与非常旧的工具/库保持向后兼容会限制能够整合的新功能和能力。SciPy 采取了一种相对保守的方法，在主要平台上与 Python 和 NumPy 的几个主要发布兼容。（这本身可能会进一步限制。请参见 C 编译器部分的示例。）

首先，SciPy 是一个 Python 项目，因此需要 Python 环境。
BLAS 和 LAPACK 数值库需要安装。
需要 C、C++、Fortran 代码的编译器，以及 Cython 和 Pythran（后者目前是选择性的退出）
Python 环境需要安装NumPy包。
测试需要pytest和hypothesisPython 包。
构建文档需要matplotlib、Sphinx 和MyST-NB包以及 PyData 主题。

用于构建 CPython 的工具对构建 SciPy 的工具有一些影响。它还影响文档中使用的示例（例如，函数的文档字符串），因为这些示例只能使用所有支持的配置中存在的功能。

构建 SciPy

Python 版本

SciPy 兼容多个版本的 Python。在放弃对较旧 Python 版本的支持时，SciPy 遵循 NEP 29 [1]的指导。从 SciPy 1.3 开始，不再支持 Python 2.7。

日期	支持的 Python 版本
2018	Py2.7, Py3.4+（SciPy 1.2.x 是最后一个支持 Python 2.7 的发布版本）
2019	Py3.5+（但未移除 Py2.7 特定代码）
2020	Py3.6+（允许移除 Py2.7 特定代码）
2021	Py3.7+
2022	Py3.8+

NumPy

SciPy 依赖于 NumPy，但 SciPy 的发布与 NumPy 的发布没有直接关系。SciPy 尝试与至少前 4 个 NumPy 版本兼容。特别地，SciPy 不能仅仅依赖最新的 NumPy 功能，而是需要使用这 4 个版本中通用的功能来编写[2]。

该表显示了适用于每个主要 Python 版本的 NumPy 版本。

SciPy 版本	Python 版本	NumPy 版本
1.2	2.7, >=3.4, <=3.7	>=1.8.2, <= 1.16.x
1.4	>=3.5, <=3.8	>=1.13.3, <= 1.17.3
1.5	>=3.6, <=3.9	>=1.14.5, <= 1.19.3
1.6	>=3.7, <=3.9	>=1.16.5, <= 1.20.x
1.7.0/1	>=3.7, ❤️.10	>=1.16.5, <1.23.0
1.7.2/3	>=3.7, ❤️.11	>=1.16.5, <1.23.0
1.8	>=3.8, ❤️.11	>=1.17.3, <1.24.0
1.9.0/1	>=3.8, ❤️.12	>=1.18.5, <1.25.0
1.9.2	>=3.8, ❤️.12	>=1.18.5, <1.26.0
1.10	>=3.8, ❤️.12	>=1.19.5, <1.26.0
1.11	>=3.9, ❤️.12	>=1.21.6, <1.27.0
1.12	>=3.9, ❤️.13	>=1.22.4, <2.0.0

在特定情况下，例如特定架构，这些要求可能会有所不同。请查看发布说明[3]和元包oldest-supported-numpy以获取更多信息[4]。

编译器

构建 SciPy 需要 C、C++、Fortran 编译器以及 Python 转译器 Cython 和 Pythran（后者是从版本 1.7.0 开始的可选依赖项）。

为了保持与大量平台和设置的兼容性，特别是在无法使用官方 wheels（或其他分发渠道如 Anaconda 或 conda-forge）的情况下，SciPy 试图保持与旧编译器的兼容性，尚未达到官方生命周期结束的平台。

如下所述，当前的最小编译器版本为：

Compiler	默认平台（已测试）	次要平台（未测试）	最小版本
GCC	Linux	AIX、Alpine Linux、OSX	GCC 8.x
LLVM	OSX	Linux, FreeBSD, Windows	LLVM 10.x
MSVC	Windows		Visual Studio 2019 (vc142)

请注意，LLVM 的下限并未强制执行。较旧版本应该可以工作 - 只要它们支持核心（非标准库）C++17 - 但在开发过程中没有测试 LLVM 12 以下的任何版本。如果在编译过程中遇到问题，请提交问题报告。

官方构建

目前，SciPy 的 wheel 构建如下：

平台	CI 基础镜像[5] [6] [7]	编译器	备注
Linux x86	`ubuntu-22.04`	GCC 10.2.1	`cibuildwheel`
Linux arm	`docker-builder-arm64`	GCC 11.3.0	`cibuildwheel`
OSX x86	`macOS-11`	clang-13/gfortran 11.3.0	`cibuildwheel`
OSX arm	`macos-monterey-xcode:14`	clang-13.1.6/gfortran 12.1.0	`cibuildwheel`
Windows	`windows-2019`	GCC 10.3（rtools）	`cibuildwheel`

注意在 OSX 上，额外提供了 gfortran 11.3.0 用于 x86_64，以及 gfortran 12.1.0 用于 arm64。请参见tools/wheels/cibw_before_build_macos.sh。

C 编译器

SciPy 兼容大多数现代 C 编译器（特别是clang）。如今，所有相关编译器对最近的 C 语言标准都有合理的支持，尽管这与以往截然不同。以下段落主要讨论这些限制的演变；不关心历史背景的读者可以直接跳到末尾的表格。

在过去，相关平台上最具限制性的 C 支持编译器是微软 Visual C++编译器及工具集（合称 MSVC）[8] [9]。直到 Visual Studio 2013，每个 MSVC 版本都附带一个更新的 C Runtime（CRT）库，与之前的版本不兼容。

应用程序二进制接口（ABI）的不兼容性意味着所有希望通过此接口进行通信（例如调用共享库中的函数）的项目都需要使用相同的 MSVC 版本进行（重新）编译。CPython 2.7 的长期支持意味着 Python 本身长时间以来一直使用 VS 2008（为了在补丁发布中不破坏 ABI），因此 SciPy 也一直停留在那个版本。

使用 VS 2008（不支持 C99）为 CPython 2.7 编译构建版本，长时间以来意味着 SciPy 中的 C 代码必须符合早期的 C90 语言和标准库标准。在 SciPy 1.3.x 中放弃对 CPython 2.7 的支持后，这一限制终于被解除（尽管一开始只是逐步解除）。

自从发布 Visual Studio 2015 以来，引入了“Universal C Runtime”（UCRT）[10]，C Runtime 的 ABI 已经稳定，这意味着不再需要在 SciPy 中使用与底层 CPython 版本相同的编译器版本的限制。然而，这种稳定性并非永久性：微软一直在计划[11]发布破坏 ABI 的版本 - 跨编译器和 C/C++标准库 - （暂时称为“vNext”），但目前尚不清楚具体时间。一旦这种情况发生，SciPy 将再次受到最多与最新 ABI 兼容的 Visual Studio 版本的限制（目前为 VS 2022），直到根据 NEP29 支持的所有 CPython 版本都使用了与 vNext 兼容的编译器为止。

具体而言，微软 Visual Studio 版本与目标“工具集”的版本之间有区别，工具集被定义为“Microsoft C++编译器、链接器、标准库及相关工具”。每个 Visual Studio 版本都附带一个默认的 MSVC 工具集版本（例如 VS2017 带有 vc141，VS2019 带有 vc142），但在较新版本的 Visual Studio 中也可以针对旧的工具集进行目标设置。由于编译器的性质（即前端和后端分离），支持给定特性（例如在 C 中）的限制因素是 Visual Studio 版本还是工具集，这取决于具体情况，但总体而言，后者是一个更难以突破的障碍，因此是实际的下限。

这是因为尽管工具集版本之间的 ABI 保持兼容（直到 vNext），但所有链接操作必须使用至少与用于构建任何涉及工件的工具集一样新的工具集，这意味着工具集版本提升往往会是“传染性的”，即需要所有消费库也提升其工具集（和可能的编译器）版本。这对 NumPy 而言比 SciPy 更为严重，因为后者只有一个较小的 C API，并且与比较少的项目编译。此外，使用更新的工具集意味着编译 C++ 代码的库的用户（如 SciPy 所做的那样）可能还需要更新的 Microsoft Visual C++ Redistributable，这可能需要分发给他们[13]。

综上所述，对于每个 SciPy 版本，MSVC 编译器或工具集的最低要求主要由当时支持的最旧 CPython 版本决定。首个将最低要求提升至此的 SciPy 版本是 1.9，原因是包含了不支持 vc141 编译的 HiGHS 子模块，以及在公共 CI 中积极删除 VS2017，使得确保所有工具集版本能够与非默认工具集版本一起使用变得不可行。

SciPy 版本	CPython 支持	MS Visual C++	工具集版本
Until 1.2	2.7 & 3.4+	VS 2008 (9.0)	vc90
1.3, 1.4	3.5+	VS 2010 (10.0)	vc100
1.5	3.6+	VS 2015 (14.0)	vc140
1.6, 1.7	3.7+	VS 2017 (14.1)	vc141
1.8	3.8+	VS 2017 (14.1)	vc141
1.9	3.8+	VS 2019 (14.20)	vc142

就 C 语言标准而言，值得注意的是 C11 具有可选特性 [14]（例如原子操作、线程），其中一些（如 VLAs 和复杂类型）在 C99 标准中是强制性的。C17（有时称为 C18）可以视为对 C11 的错误修正，因此通常可以跳过 C11。

SciPy 受可用编译器支持的先进语言特性限制，尤其是微软公司花费了很长时间才达到对 C99/C11/C17 的一致性，然而从 MS Visual Studio 16.8 开始，已支持 C11/C17 [15]（尽管没有 C11 可选特性）。对于 SciPy 而言，C99 <complex.h> 特别有趣；MSVC 对此和 <stdatomic.h> 的一致性正在这里追踪 [16] [17]。然而，仍然可以在 Windows 上使用复杂类型，只要使用特定于 Windows 的类型即可[18]。

因此，只有在 Windows 上得到支持时才能使用超出 C90 的 C 特性；然而，截至 2021 年底，使用了足够新的编译器。这是因为 GCC 和 LLVM 在其当前使用的最旧版本上支持所有相关的 C11 特性，而 C17 只是对 C11 的错误修正，如前所述。简而言之：

日期	C 标准
<= 2018	C90
2019	对于旧代码采用 C90，可能考虑对新代码采用 C99
2020	C99（无 `<complex.h>`, `<stdatomic.h>`, `<threads.h>` 和 VLAs）
2021	C17（无 `<complex.h>`, `<stdatomic.h>`, `<threads.h>` 和 VLAs）
?	C23、`<complex.h>`、`<stdatomic.h>`、…

C++ 语言标准

对于 SciPy 来说，C++语言标准通常是指导方针，而非官方决策。这一点尤其适用于尝试预测新标准采用时间表。

Date	C++ 标准
<= 2019	C++03
2020	C++11
2021	C++14
2022	C++17（核心语言 + 通用库特性）
?	C++17（具备完整的标准库）、C++20、C++23

放弃对 Python 2.7 的支持后，可以普遍使用 C++11，并且在放弃对 Python 3.6 后，Visual Studio 版本（由于与 CPython 的 ABI 兼容性而曾被限制在 14.0 版本）已足够新，甚至支持 C++17。

由于官方构建（详见上文）使用了相当新的 LLVM 版本，因此 C++ 支持的瓶颈是最旧支持的 GCC 版本，而 SciPy 主要受到最旧支持的 manylinux 版本和镜像中的版本的限制 [19]。

在 2021 年底（最终移除 manylinux1 wheels），GCC 的最低要求移至 6.3 版本，该版本具备完整的 C++14 支持 [20]。这对应于相关 manylinux 版本中存在的最低 GCC 版本，尽管与以前基于 RHEL 衍生的 CentOS 的 manylinux 镜像不同，后者可以从 “RHEL Dev Toolset” 中获益，支持兼容 ABI 的 GCC 后移版本，但 manylinux_2_24 却停留在 GCC 6.3 版本。由于这些过时的编译器，该镜像未能成功 [21]，并在 2022 年中旬到达其生命周期结束 [22]。出于不同原因，manylinux2010 也在同一时期达到了其生命周期结束 [23]。

现有的 manylinux2014 和 manylinux_2_28 镜像目前分别支持 GCC 10 和 11。后者将在新的 GCC 版本推出时继续更新为后移版本，但前者可能不会改变，因为 CentOS 项目已不再响应发布 GCC 11 的 aarch64 后移版本 [24]。

这使得所有主要平台及其编译器都具备相对较新的版本。然而，SciPy 在历史上也努力支持不太常见的平台，即使不能提供二进制构件（即 wheels），也能通过源码编译支持 - 这包括例如 AIX、Alpine Linux 和 FreeBSD。

对于 AIX 7.1 和 7.2，默认编译器是 GCC 8（AIX 6.1 在 2017 年已经到达生命周期结束），但可以安装（并行使用）GCC 10 [25]。当前支持的最旧 Alpine Linux 发行版是 3.12 [26]，已经带有 GCC 10。对于 FreeBSD，当前支持的最旧 12.x 版本 [27] 配备了 LLVM 10（并且 GCC 10 可以作为 freebsd-port 安装 [28]）。

最后，还有一个问题，即哪些机器被广泛用于需要编译 SciPy 源代码的人（例如 SciPy 开发人员，或因性能原因想自行编译的人）。最旧的相关发行版（不带有 RHEL 风格的后端支持）是 Ubuntu 18.04 LTS（带有 GCC 7 但也有 GCC 8 的后端支持；Ubuntu 20.04 LTS 带有 GCC 9）和 Debian Buster（带有 GCC 8；Bullseye 带有 GCC 10）。这是确定编译器支持下限的最弱限制（可以预期，电脑高手和开发人员会保持系统至少有些更新，或者使用可用的后端支持），随着老旧发行版的使用量逐渐减少，这种限制逐渐变得不那么重要。

所有当前支持的最低版本的编译器（GCC 8，LLVM 12，VS2019 with vc142）均完全支持 C++17 核心语言，因此可以无条件使用。然而，截至 2022 年中，尚未在所有编译器中完成对 C++17 标准库的完整支持 [20]，特别是 LLVM。因此，在将其用于 SciPy 之前，需要检查所有编译器是否支持特定的 stdlib 特性。对于 C++20 和 C++23，编译器的支持仍在积极开发中 [20]。

Fortran 编译器

通常情况下，任何维护良好的编译器都可能适用并可用于构建 SciPy。

工具	版本
gfortran	>= 4.8.0
ifort	最近版本
flang	最近版本

Cython & Pythran

SciPy 总是需要一个最新的 Cython 编译器。自 1.7 版本开始，Pythran 是一个构建依赖项（目前可以选择不使用）。

OpenMP 支持

出于各种原因 [29]，SciPy 不能带有内置的 OpenMP 支持。在使用可选的 Pythran 支持时，可以在构建源码时生成支持 OpenMP 的并行代码。

其他库

任何符合 BLAS/LAPACK 接口的库均可使用。已知可用的有 OpenBLAS、ATLAS、MKL、BLIS 和参考 Netlib 库。

库	最低版本
LAPACK	3.7.1
BLAS	OpenBLAS、MKL 或 ATLAS 的最新版本。不再支持 Accelerate BLAS 库。

还有一些额外的可选依赖项。

库	版本	网址
mpmath	最近版本	`mpmath.org/`
scikit-umfpack	最近版本	`pypi.org/project/scikit-umfpack/`
pooch	最近版本	`pypi.org/project/pooch/`

此外，SciPy 还支持与其他库的交互。测试套件在安装这些库时运行了额外的兼容性测试：

工具	版本	网址
pydata/sparse	最近版本	`github.com/pydata/sparse/`

测试与基准测试

测试与基准测试需要使用最新版本的：

工具	版本	网址
pytest	最新版本	`docs.pytest.org/en/latest/`
Hypothesis	最新版本	`hypothesis.readthedocs.io/`
asv (airspeed velocity)	最新版本	`asv.readthedocs.io/`

构建文档

工具	版本
Sphinx	最新版本即可，要求 >= 2.0.
PyData Sphinx 主题	最新版本即可，要求 >= 0.8.1。
Sphinx-Design	最新版本即可，要求 >= 0.2.0。
numpydoc	最新版本即可，要求 >= 0.8.0。
matplotlib	通常建议 >= 2.0。
MyST-NB	最新版本即可，要求 >= 0.17.1

注意

开发者注意事项：所需的numpy和matplotlib版本对 Python 文档字符串中的示例有影响。示例必须能够在用于构建文档的环境中执行，也必须能够与用户可能在此版本的 SciPy 中使用的任何支持的numpy/matplotlib版本一起执行。

打包

工具	版本	URL
setuptools	最新版本	`pypi.org/project/setuptools/`
wheel	最新版本即可	`pythonwheels.com`
multibuild	最新版本	`github.com/matthew-brett/multibuild`

参考资料

SCIPY 组织

SciPy 核心开发者指南

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/core-dev/index.html

决策过程

SciPy 有一个正式的治理模型，详见 SciPy 项目治理。以下部分以非正式方式记录了关于代码和提交权限决策的实际情况。正式的治理模型为主导，以下内容仅供参考。

代码

对于添加（或不添加）新功能、破坏向后兼容性或对代码库进行其他重大更改的任何重大决策，应在 scipy-dev 邮件列表上进行讨论（最好达成全体一致）。

任何非微不足道的更改（微不足道指拼写错误或一行维护提交）都必须通过拉取请求（PR）进行。它必须由另一名开发者审查。如果审查不及时发生，并且重要的是快速合并 PR，提交者应该向邮件列表发送消息，表示他/她打算在时间 X 之前合并该 PR，理由是 Y，除非有人在那之前审查它。

更改和新添加应该进行测试。未经测试的代码是有问题的代码。

提交权限

谁拥有提交权限由 SciPy 指导委员会决定；提交权限的更改将在 scipy-dev 邮件列表上宣布。

决定新增功能

迄今为止，接受建议的新功能的一般决策规则一直是有条件的：

这种方法在许多领域都适用，并且“普遍认为”是有用的，
它适合于子模块的主题，且不需要大量支持框架来运行，
实现看起来很合理，并且未来不太可能需要太多调整（例如，预期的维护负担有限），
有人希望贡献它，以及
有人希望审查它。

最后的标准通常是建议功能的一个槽点。在代码经过彻底审查之前，代码是不能合并的，而且总是有维护任务积压，竞争审阅者的时间。理想情况下，贡献者在开始工作之前应该找到一个具有适当领域专业知识的审阅者。

虽然很难对“普遍有用和普遍认为有效”给出明确的规则，但可以将以下因素相互对比：

这种方法在实践中在不同领域中使用/有用吗？使用它需要多少领域特定的背景知识？
考虑已经在模块中的代码。你所添加的是一种遗漏吗？它解决了你期望模块能够解决的问题吗？它是否以显著方式补充了现有功能？
考虑通常预期的类似方法/功能的等价类。其中，原则上哪些是最小集合，以便所提供的功能中没有明显遗漏？那会是多少东西？包括代表性的一个是否涵盖了大多数用例？原则上，将最小集合中的所有内容都包括在模块中是否合理？
您正在添加的内容是否在文献中有很好的理解？如果不是，您对它能够成功的信心有多大？该方法与其他类似方法相比表现如何？
请注意，每年两次的发布周期和向后兼容性政策使得稍后纠正事物变得更加困难。

子模块的范围也有所不同，因此最好将每个子模块视为单独的项目 - “特殊函数的数值评估”相对而言定义较好，但“常用的优化算法”则较少定义。

在 GitHub 上开发

SciPy 的开发主要在 GitHub 上进行；本节描述了处理问题、拉取请求和管理主要scipy存储库的预期工作方式。

标签和里程碑

每个问题和拉取请求通常至少会获得两个标签：一个用于主题或组件（scipy.stats，Documentation等），另一个用于问题或拉取请求的性质（enhancement，maintenance，defect等）。根据情况可能添加其他标签：

easy-fix：适合新贡献者解决的问题。
needs-work：具有未解决审查评论的拉取请求。
needs-decision：需要决策的问题或拉取请求。
needs-champion：适用于原始作者未完成但值得恢复的拉取请求。
backport-candidate：应由发布经理考虑将其回溯修复的 bug 修复。

为计划发布的每个版本号创建一个里程碑。需要为特定版本解决的问题和需要合并的拉取请求应设置为相应的里程碑。在合并拉取请求后，其里程碑（以及关闭的问题的里程碑）应设置为即将到来的下一个版本 - 这样可以轻松查看更改的概述，并将其完整列表添加到发布说明中。

拉取请求审查工作流程

在审查拉取请求时，请利用拉取请求工作流程功能，参见使用工作流程功能。

处理拉取请求

当合并贡献时，提交者负责确保这些贡献符合贡献 SciPy中概述的要求。还要检查新功能和向后兼容性破坏是否在 scipy-dev 邮件列表上进行了讨论。
新代码通过拉取请求（PR）进入。
使用绿色按钮合并新代码。如果出现合并冲突，请要求 PR 提交者进行变基（可能需要提供一些 git 指令）。
回溯和微不足道的添加以完成 PR（确实微不足道，比如拼写错误或 PEP8 修复）可以直接推送。
对于添加新功能或以某种方式复杂的 PR，请至少等待一两天再合并。这样，其他人有机会在代码进入之前进行评论。
挤压提交或清理您认为太混乱的 PR 提交消息是可以的。但在此过程中，请务必保留原作者的姓名。
确保合并的 PR 上的标签和里程碑设置正确。
当您想要拒绝一个 PR 时：如果非常明显，您可以直接关闭并解释原因；如果不明显，则最好首先解释为什么您认为 PR 不适合包含在 SciPy 中，然后让第二个合作者进行评论或关闭。

回溯

所有的 PR（无论是增强、错误修复还是其他内容）都应该提交到主分支。只有错误修复才有资格回溯到维护分支。SciPy 的回溯策略是：（a）只回溯重要的修复；（b）只有在合理确定相关维护分支上会发布新的 bug 修复版本时才回溯。通常，合并重要 bug 修复的开发人员会添加backport-candidate标签并联系发布经理，后者决定是否以及何时进行回溯。回溯完成后，必须再次删除backport-candidate标签。

回溯 PR 的一个好策略是将几个主分支的 PR 合并在一起，以减少持续集成测试的负担并减少维护分支历史记录中的合并提交混乱。通常最好为回溯 PR 中代表的每个主分支 PR 保留一个提交。这样，历史记录清晰，并且如果需要的话可以直接撤销。

发布说明

当 PR 合并时，请考虑是否需要在发布说明中提及更改内容。需要提及的内容包括：新功能、不向后兼容的更改、弃用以及“其他更改”（任何其他值得注意的内容，请参阅较早的发布说明，了解值得提及的内容种类）。

发布说明条目在 wiki 上维护（例如github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.2.0）。发布经理将从那里收集内容，并将其整合到 html 文档中。我们使用这种机制来避免每个 PR 直接触及doc/release/下同一文件时可能发生的合并冲突。

更改可以通过Atom feed进行监控，并进行拉取（wiki 是一个 git 仓库：https://github.com/scipy/scipy.wiki.git）。

其他

PR 状态页面： 当向拉取请求添加新提交时，GitHub 不会发送任何通知。然而，needs-work标签可能已不再适用。此页面提供了更新的 PR、需要审查、需要决策等概述。

交叉引用： 在 GitHub 上交叉引用问题和拉取请求通常很有用。GitHub 允许使用gh-xxxx或#xxxx来进行引用，其中xxxx是问题/PR 编号。强烈推荐使用gh-xxxx格式，因为清楚表明这是一个 GitHub 链接。旧问题包含 Trac（我们在 GitHub 之前使用的系统）票据的#xxxx。

PR 命名约定： 拉取请求、问题和提交消息通常以ENH:或BUG:等三个字母缩写开头。这对于快速了解提交/PR/问题的性质非常有用。有关缩写的完整列表，请参见编写提交消息。

许可证

SciPy 采用修改后的BSD 许可证（3 条款）进行分发。所有由贡献者添加到 SciPy 的代码、文档和其他文件均根据此许可证授权，除非源代码明确指定了另一许可证。贡献者保留他们编写并提交到 SciPy 的代码的版权。

其他与 SciPy 使用的修改后 BSD 许可证兼容的许可证包括 2 条款 BSD、MIT 和 PSF。不兼容的许可证包括 GPL、Apache 以及要求归属/引用或禁止商业用途的自定义许可证。

PR 通常包含从未经许可的代码或来自不兼容 SciPy 许可证的默认许可的代码或其派生的内容。例如，在 StackOverflow 上发布的代码受 CC-BY-SA 许可证保护，由于共享条款的存在，这些贡献无法被纳入 SciPy。除非原始代码的作者愿意根据修改后的 BSD（或兼容的）许可证重新许可其代码，否则这些贡献将无法被接受。如果原始作者同意，请在源文件中添加一条注释以此说明，并将相关通信转发给 scipy-dev 邮件列表。

另一种常见情况是代码是从 R、Octave（都是 GPL 许可）或商业应用程序的代码翻译或派生而来。此类代码也无法包含在 SciPy 中。但是，只要作者没有查看不兼容许可源代码的原始实现，通过相同 API 实现功能是可以的。## 版本编号

SciPy 版本编号遵循PEP 440。发布的最终版本（这些版本是唯一出现在PyPI上的版本）编号为MAJOR.MINOR.MICRO，其中：

MAJOR是一个整数，表示主要版本。它很少更改；MAJOR的变化表示大（可能不兼容）的更改。
MINOR是一个整数，表示次要版本。次要版本通常每年发布两次，可能包含新功能、弃用和错误修复。
MICRO是一个整数，表示错误修复版本。错误修复版本在需要时发布，通常每个次要版本一到两个版本。它们不能包含新功能或弃用。

发布的 alpha、beta 和 rc（发行候选）版本编号与最终版本相同，但分别带有后缀a#、b#和rc#，#为整数。开发版本带有后缀.dev0+<git-commit-hash>。

有效的 SciPy 版本字符串示例：

0.16.0
0.15.1
0.14.0a1
0.14.0b2
0.14.0rc1
0.17.0.dev0+ac53f09

安装的 SciPy 版本包含这些版本标识符：

scipy.__version__            # complete version string, including git commit hash for dev versions
scipy.version.short_version  # string, only major.minor.micro
scipy.version.version        # string, same as scipy.__version__
scipy.version.full_version   # string, same as scipy.__version__
scipy.version.release        # bool, development or (alpha/beta/rc/final) released version
scipy.version.git_revision   # string, git commit hash from which scipy was built 
```## 弃用

有各种各样的原因希望删除现有功能：它有 bug，API 难以理解，它被性能更好的功能所取代，它需要移动到另一个 SciPy 子模块等等。

通常不建议在未事先警告用户的情况下删除某些内容。因此，在从公共 API 中删除某些内容之前，应执行以下操作：

1.  建议在 scipy-dev 邮件列表上提议弃用该功能，并获得同意认为这样做是可以接受的。

1.  为此添加一个`DeprecationWarning`，指出该功能已被弃用，并指明是在哪个版本中。对于 Cython API，请参阅 Deprecating public Cython APIs 获取实际步骤。

1.  在该版本的发布说明中提及该弃用。

1.  在引入`DeprecationWarning`的发布日期后至少等待 6 个月，然后再删除该功能。

1.  在发布说明中提及该功能的移除。

实际上，6 个月的等待期通常意味着等待两个版本。在引入警告时，还要确保在运行测试套件时过滤掉这些警告，以免污染输出。

可能有理由希望忽略某个特定弃用策略：这总是可以在 scipy-dev 邮件列表上讨论的。## 分发

分发 Python 包是一个非常棘手的问题 - 特别是对于像 SciPy 这样具有复杂构建要求的包 - 并且可能会发生变化。有关推荐工具和技术的最新概述，请参阅[Python Packaging User Guide](https://packaging.python.org)。本文档讨论了 SciPy 的一些主要问题和考虑事项。

### 依赖项

依赖项是用户必须安装的东西，以便使用（或构建/测试）一个包。它们通常会带来麻烦，特别是如果它们是必需的。SciPy 试图将其依赖项保持在最低限度；目前它们包括：

*无条件运行时依赖：*

+   [NumPy](https://numpy.org)

*条件运行时依赖：*

+   pytest（用于运行测试套件）

+   [asv](https://asv.readthedocs.org)（用于运行基准测试）

+   [matplotlib](https://matplotlib.org)（用于一些可以生成图形的函数）

+   [pooch](https://www.fatiando.org/pooch/latest/)（用于 scipy.datasets 模块）

+   [Pillow](https://pillow.readthedocs.org)（用于图像加载/保存）

+   [scikits.umfpack](https://pypi.org/project/scikit-umfpack)（在`sparse.linalg`中可选使用）

+   [mpmath](http://mpmath.org)（用于`special`中更多的扩展测试）

+   pydata/sparse（在`scipy.sparse`中的兼容性支持）

+   [threadpoolctl](https://github.com/joblib/threadpoolctl)（用于控制测试套件中的 BLAS/LAPACK 线程）

+   [Hypothesis](https://hypothesis.readthedocs.io/en/latest/index.html)（用于运行特定的单元测试）

*无条件的构建时依赖：*

+   [Numpy](https://numpy.org)

+   BLAS 和 LAPACK 实现（参考 BLAS/LAPACK，ATLAS，OpenBLAS，MKL 都已知可用）

+   [Cython](https://cython.org)

+   [setuptools](https://github.com/pypa/setuptools)

+   [pybind11](https://github.com/pybind/pybind11)

*有条件的构建时依赖：*

+   [wheel](https://wheel.readthedocs.io/)（`python setup.py bdist_wheel`）

+   [Sphinx](http://www.sphinx-doc.org/)（文档）

+   [PyData Sphinx 主题](https://pydata-sphinx-theme.readthedocs.io/en/latest/)（文档）

+   [Sphinx-Design](https://sphinx-design.readthedocs.io)（文档）

+   [matplotlib](https://matplotlib.org)（文档）

+   [MyST-NB](https://myst-nb.readthedocs.io/)（文档）

当然，构建 SciPy 还需要 C、C++和 Fortran 编译器，但我们不认为这些是依赖关系，因此这里不讨论它们。详情请参见[`scipy.github.io/devdocs/dev/contributor/building.html`](https://scipy.github.io/devdocs/dev/contributor/building.html)。

当一个软件包提供了有用的功能并且被提议作为一个新的依赖时，考虑是否有必要代理（即与 scipy 一起提供该软件包的副本）。例如，[decorator](https://github.com/micheles/decorator) 在 `scipy._lib` 中被代理。

唯一报告给[pip](https://pip.pypa.io/en/stable/)的依赖是[Numpy](https://numpy.org)，请参阅 SciPy 主要的`setup.py`中的`install_requires`。其他依赖项对于 SciPy 的正确功能并不需要。

#### 依赖处理的问题

Python 打包工具如何处理项目报告的依赖关系存在一些问题。由于 SciPy 定期收到此类错误报告，我们在这里稍作详细说明。

如果系统上完全未安装 NumPy，或者在使用 `bdist_wheel` 构建 wheels 时，SciPy 仅通过 `install_requires` 报告其对 NumPy 的依赖。SciPy 不再使用 `setup_requires`（过去调用 `easy_install`），构建依赖项现在仅通过 `pyproject.toml` 处理。`pyproject.toml` 遵循 PEP 517；`pip` 提供了 `--no-use-pep517` 和 `--no-build-isolation` 标志，可能会忽略或以不同方式处理 `pyproject.toml` - 如果用户使用这些标志，则需要自行安装正确的构建依赖项。

#### NumPy 和其他依赖项的版本范围

对于依赖项，设置它们版本的下限和上限非常重要。对于*构建时*依赖项，它们在`pyproject.toml`中指定，并且版本仅适用于 SciPy 本身的构建。对于诸如`wheel`或`setuptools`之类的依赖项，可以指定范围或特定版本。对于 NumPy，我们还必须考虑 ABI 兼容性，因此我们使用`==`指定到最低支持的版本（因为 NumPy 的 ABI 是向后兼容但不是向前兼容）。

对于*运行时依赖项*（目前仅有 `numpy`），我们在`pyproject.toml`和`setup.py`的`install_requires`中指定版本范围。设置正确的上限值略微棘手。如果我们不设置任何限制，那么几年后可能会引入一个太新的版本，并且 NumPy 可能会在此期间弃用并删除 SciPy 依赖的某些 API。另一方面，如果我们将上限设置为最新已发布的版本，那么一旦发布新的 NumPy 版本，将不会有与之兼容的 SciPy 版本。考虑到 NumPy 和 SciPy 都以每年两次的节奏发布，并且在 NumPy 中弃用的功能应该在未来两个版本中保留，我们将上限设置为 `<1.xx+3.0`（其中 `xx` 是最新已发布的 NumPy 的次要版本）。### 支持的 Python 和 NumPy 版本

SciPy 支持的 [Python](https://www.python.org) 版本在`setup.py`的 PyPI 分类列表中列出，并且在每个发布的发行说明中提到。所有新发布的 Python 版本将尽快得到支持。关于放弃支持 Python 或 NumPy 版本的一般政策，请参阅 [NEP 29](https://numpy.org/neps/nep-0029-deprecation_policy.html#nep29 "(在 NumPy Enhancement Proposals 中)")。最终放弃支持的决定始终由 scipy-dev 邮件列表决定。

SciPy 版本对应的最低支持的 [NumPy](https://numpy.org) 版本在发行说明中提到，并且编码在`pyproject.toml`、`scipy/__init__.py`以及`setup.py`的`install_requires`字段中。通常，最新的 SciPy 发布支持约 5-7 个 NumPy 的次要版本：最多支持 2.5 年前的 NumPy 版本（考虑到 NumPy 发布频率约为每年 2 次），再加上未来两个版本。

可选依赖项和编译器支持的受支持版本在 Toolchain Roadmap 中有文档化。请注意，并非所有受支持的可选依赖项版本都经过 SciPy 的持续集成设置的充分测试或根本未经测试。有关此问题的问题已在问题跟踪器或邮件列表中解决。

### 构建二进制安装程序

注意

本节仅关于构建 SciPy 二进制安装程序以 *分发*。有关在将来使用的同一台计算机上构建 SciPy 的信息，请参阅 [此 scipy.org 页面](https://scipy.github.io/devdocs/dev/contributor/building.html)。

在构建二进制文件并在 PyPI 或其他地方分发它们时，有许多需要考虑的因素。

**General**

+   一个二进制文件特定于单个 Python 版本（因为不同的 Python 版本在至少到 Python 3.4 之前不兼容 ABI）。

+   构建时请针对需要支持的最低 NumPy 版本进行构建，然后它将适用于所有具有相同主版本号的 NumPy 版本（NumPy 确实保持向后 ABI 兼容性）。

+   用于构建可移植 SciPy 二进制文件的最简单可用工具链是我们的 `cibuildwheel` 基础设施，适用于常见平台，详细信息可在我们的 CI 基础设施代码中找到，并通过 Windows、Linux 和 MacOS 上的 `cibuildwheel` 命令使用，尽管在某些情况下可能需要一些额外的外部依赖项。

**Windows**

+   对于使用免费工具链构建的 64 位 Windows 安装程序，请使用文档化方法，位于 [`github.com/numpy/numpy/wiki/Mingw-static-toolchain`](https://github.com/numpy/numpy/wiki/Mingw-static-toolchain)。一旦确保该工具链的维护是可持续的长期，该方法可能会被用于 SciPy 本身。有关详细信息，请参阅 [MingwPy](https://mingwpy.github.io) 项目和 [此线程](https://mail.python.org/pipermail/numpy-discussion/2015-October/074056.html)。

+   在 Windows 上生成 64 位安装程序的另一种方法是使用 `icc`、`ifort` 和 `MKL`（或者使用 `MSVC` 替代 `icc`）。有关 Intel 工具链的详细说明，请参阅 [本文](https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl)，而有关（部分）MSVC 说明，请参阅 [此 wiki 页面](https://github.com/numpy/numpy/wiki/Building-with-MSVC)。

+   旧版 SciPy 发布包含一个 `.exe` 的“超级包”安装程序。这些包含了 3 个完整的构建版本（没有 SSE、SSE2、SSE3），并且是使用 [`github.com/numpy/numpy-vendor`](https://github.com/numpy/numpy-vendor) 构建的。这种构建设置已经众所周知不再有效并且不再受支持。它使用的是 g77 而不是 gfortran，这是由于复杂的 DLL 分发问题（参见 [gh-2829](https://github.com/scipy/scipy/issues/2829)）。由于该工具链不再受支持，不再需要 g77 支持，现在 SciPy 可以包含 Fortran 90/95 代码。

**Linux**

+   可以通过[manylinux](https://github.com/pypa/manylinux/)项目生成与 PyPI 兼容的 Linux 轮子，这在我们的 `cibuildwheel` 基础设施中使用。

其他 Linux 构建设置导致 PyPI 不兼容的轮子，这些轮子需要通过自定义渠道分发，例如在[Wheelhouse](https://pypi.org/project/Wheelhouse)中查看，在[wheel](https://wheel.readthedocs.io/)和[Wheelhouse](https://pypi.org/project/Wheelhouse)文档中。## Making a SciPy release

在最高层次上，这是发布经理发布新的 SciPy 版本所做的事情：

1.  在 scipy-dev 邮件列表上提出一个发布时间表。

1.  为发布创建维护分支。

1.  给发布版本打标签。

1.  构建所有发布工件（源代码、安装程序、文档）。

1.  上传发布工件。

1.  公布发布消息。

1.  将相关更改移植到发布说明和构建脚本到主分支。

在本指南中，我们试图详细描述如何执行上述每个步骤。除了必须由发布经理执行的步骤外，这里还描述了与发布相关的活动和利益的约定：

+   后移操作

+   标签和里程碑

+   版本编号

+   支持的 Python 和 NumPy 版本

+   弃用信息

### 提出发布时间表。

典型的发布周期如下：

+   创建维护分支。

+   发布 beta 版本。

+   发布“发布候选版”（RC）。

+   如果需要，发布一个或多个新的 RC。

+   一旦最后一个发布候选版没有问题，发布最终版本。

通常每个步骤之间至少有一周的时间。经验表明，新的次要版本需要 4 到 8 周的周期。Bug 修复版本不需要 beta 或 RC，并且可以更快完成。

理想情况下，最终发布与最后一个 RC 相同，但可能会有轻微差异 - 由发布经理判断风险。通常情况下，如果编译代码或复杂的纯 Python 代码发生变化，则需要新的 RC，而从主分支后移的简单错误修复则不需要新的 RC。

要提出时间表，请发送一个列表，包含分支、beta/rc/final 发布的预计日期给 scipy-dev。在同一封电子邮件中，请大家检查是否有重要问题/PR 需要包含，但未标记为发布里程碑或“backport-candidate”标签。

### 创建维护分支。

在分支之前，请尽可能更新发布说明。在发布说明中包括 `tools/gh_lists.py` 和 `tools/authors.py` 的输出。

维护分支命名为 `maintenance/<major>.<minor>.x`（例如 0.19.x）。要创建一个分支，只需将带有正确名称的分支推送到 scipy 仓库。立即在主分支上推送一个增加版本号并添加该新版本发布说明的提交。发送电子邮件到 scipy-dev，让人们知道您已完成此操作。

### 更新版本切换器

需要更新版本切换器下拉菜单中的新发布信息。

+   `doc/source/_static/version_switcher.json`：添加新发布版本以及新的开发版本。

### 更新依赖项的上限

在主分支中，我们不设置上限，因为我们希望在那里测试新的发布版或开发版本的依赖项。但是，在维护分支中，目标是能够创建多年有效的发布版本。因此，必须设置正确的上限。创建维护分支后，必须更新以下位置：

+   `pyproject.toml`：所有构建时的依赖项，以及支持的 Python 版本

    和 NumPy 版本

+   `setup.py`：支持的 Python 和 NumPy 版本

+   `scipy/__init__.py`：用于 NumPy 版本检查

每个文件都有描述如何设置正确上限的注释。

### 标记发布

首先确保您已正确设置 GPG。参见 [`github.com/scipy/scipy/issues/4919`](https://github.com/scipy/scipy/issues/4919) 关于签署发布标签的讨论，以及 [`keyring.debian.org/creating-key.html`](https://keyring.debian.org/creating-key.html) 创建 GPG 密钥的说明（如果您没有）。请注意，在某些平台上，使用 `gpg2` 而不是 `gpg` 可能更适合，以便密码可以由 `gpg-agent` 存储，如 [`github.com/scipy/scipy/issues/10189`](https://github.com/scipy/scipy/issues/10189) 中讨论的那样。在远程准备发布时，可能需要在 `~/.gnupg/gpg-agent.conf` 中设置 `pinentry-mode loopback`，因为否则使用 `gpg2` 将通过无法访问的图形密码提示进行。

要使您的密钥更容易被识别为您自己，考虑发送您的密钥到公共密钥服务器，使用像以下命令一样：

```py
gpg --send-keys <yourkeyid>

检查分支中是否有所有相关的提交。特别是检查里程碑下的问题和 PR（github.com/scipy/scipy/milestones），标记为“backport-candidate”的 PR，以及更新并包含在 html 文档中的发布说明。

然后编辑 meson.build 和 tools/version_utils.py 来获取正确的版本号（在前者中设置 version:，在后者中设置 ISRELEASED = True），并使用像 REL: set version to <version-number> 这样的消息提交。但不要立即将此提交推送到 SciPy 仓库。

最后在本地标记发布版本使用 git tag -s <v1.x.y> （-s 确保标签已签名）。如果首选 gpg2，则可以适当执行 git config --global gpg.program gpg2。继续构建发布的工件（下一节）。只有在成功构建了 sdists 和文档后才将发布提交推送到 scipy 存储库。然后继续构建 wheels。只有在 TravisCI 和 Appveyor 上所有 wheels 成功构建后才将发布标签推送到存储库（如果失败，则必须移动标签，这是不良实践）。最后，在推送标签后，还需推送第二个提交，增加版本号并为 version: 追加 .dev0，并再次将 ISRELEASED 设置为 False。对于新的发布候选版本以及从发布候选版本到正式发布时移除 rc 附加内容也适用。

构建发布的工件

这是发布时创建的所有工件的完整列表：

sdist (scipy-x.y.y.tar.gz，用于 PyPI 和 GitHub 发布）
适用于 Windows、Linux 和 macOS 的二进制 wheels
文档（html）
一个 README.txt 文件
一个 Changelog 文件

通过运行 python -m build --sdist 生成一个 sdist（注意：我们仍需将其移入 CI 作业！），并通过运行 python dev.py notes（带有标签，请参阅 python dev.py notes --help）在存储库根目录生成 Changelog 和 README，最终在 REPO_ROOT/release/ 中生成。在本地创建签名标签后执行此操作。如果完成无误，请推送发布提交（不是标签，请参见上文）至 scipy 存储库。

要构建 wheels，请推送一个包含文本 [wheel build] 的提交到用于当前发布的分支。这将触发所有需要的 Python 版本和平台的 cibuildwheel 构建。应该已在分支后立即更新了 NumPy 和其他依赖项的适当版本固定。如果 wheel 构建显示需要通过维护分支上的后向移植修复的问题，可以删除本地标签（例如 git tag -d v1.2.0rc1）并重新在新的候选提交上执行上述标记。

cibuildwheel 基础设施从构建的 wheels 运行测试，如果测试通过，则将 wheels 上传至 anaconda.org/multibuild-wheels-staging/scipy。

从这里可以下载它们以上传到 PyPI。可以使用 tools/download-wheels.py 自动完成此操作：

$ python tools/download-wheels.py 1.5.0rc1 -w REPO_ROOT/release/installers

之后，我们希望重新生成 README 文件，以便在其中包含刚刚下载的 wheels 的 MD5 和 SHA256 校验和。再次运行 python dev.py notes。

上传发布的工件

对于发布，目前有五个网络位置可用于上传内容：

PyPI（sdist, wheels）
GitHub 发布（sdist、发布说明、Changelog）
scipy.org（发布公告）
docs.scipy.org（html 文档）

PyPI：

首先上传 wheels，然后上传 sdist：

twine upload REPO_ROOT/release/installers/*.whl
twine upload REPO_ROOT/release/installers/scipy-1.x.y.tar.gz

Github 发布：

在github.com/scipy/scipy/releases上使用 GUI 创建发布，并上传所有发布的工件。在这个阶段，推送标签并将新发布（候选版）与该标签关联是适当的。例如，git push upstream v1.2.0rc1，其中upstream表示scipy/scipy。检查之前的发布，确切确定应包括哪些工件在 GUI 上传过程中非常有用。还请注意，发布说明不会自动填充到 GitHub 上的发布描述中，手动重新格式化为 Markdown 以匹配网站上以前的发布格式是非常有帮助的。一般情况下，我们不在这些 GUI 描述中包含问题和拉取请求列表。

scipy.org:

该站点的源码位于github.com/scipy/scipy.org。通过 PR 更新content/en/news.md中的新闻部分。这仅适用于正式发布，不包括发布候选版。

docs.scipy.org:

首先，在scipy/doc/中运行make dist来构建 scipy 文档。确认它们看起来正常，然后使用make upload USERNAME=rgommers RELEASE=0.19.0将它们上传到文档服务器。请注意，需要 SSH 访问文档服务器；如果没有，请向@pv（服务器管理员）、@tylerjereddy 或@rgommers（可以上传）询问。

该网站本身的源码维护在github.com/scipy/docs.scipy.org/。在index.rst的发布表中添加新的 SciPy 版本。推送该提交，然后运行make upload USERNAME=yourusername。这仅适用于正式发布，不包括发布候选版。

结束

发送邮件宣布以下邮件列表的发布：

scipy-dev
numpy-discussion
python-announce（不包括 beta/rc 版本）

对于 beta 和 rc 版本，请在邮件中要求人们测试（运行 scipy 测试并针对其自己的代码测试），并在 GitHub 或 scipy-dev 上报告问题。

完成最终发布后，将相关更改移植到发布说明、构建脚本、tools/authors.py中的作者名称映射以及仅在维护分支上进行的任何其他更改到主分支。

SciPy API 开发指南

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/api-dev/api-dev-toc.html

对 nan_policy 的设计规范

在 scipy.special 中添加矢量化的 ufuncs
支持数组 API 标准

SciPy 项目治理

原文链接：docs.scipy.org/doc/scipy-1.12.0/dev/governance.html

本文档的目的是在普通和非常规情况下，规范 SciPy 项目使用的治理流程，并澄清决策的制定方式以及我们社区的各个元素如何互动，包括开源协作开发与可能由营利或非营利实体资助的工作之间的关系。

该项目

SciPy 项目（该项目）是一个开源软件项目。该项目的目标是开发 Python 科学计算的开源软件，特别是 scipy 软件包。由该项目开发的软件在 BSD（或类似）开源许可下发布，以公开方式开发，并托管在 scipy GitHub 组织的公共 GitHub 仓库上。

项目由一个称为贡献者的分布式开发者团队开发。贡献者是指为项目贡献代码、文档、设计或其他工作的个人。任何人都可以成为贡献者。贡献者可以隶属于任何法律实体或无隶属。贡献者通过提交、审核和讨论 GitHub Pull 请求和问题，以及参与 GitHub、邮件列表和其他渠道的开放和公开项目讨论来参与项目。项目参与的基础是开放性和透明度。

该项目社区由所有贡献者和用户组成。贡献者代表并对更大的项目社区负责，我们致力于尽可能降低贡献者和用户之间的障碍。

该项目不是法律实体，也没有与法律实体当前有任何正式关系。

治理

本节描述了该项目的治理和领导模型。

项目治理的基础是：

开放性和透明度
积极贡献
机构中立性

传统上，项目领导由贡献者的一个子集提供，称为核心开发者，他们的积极和持续贡献通过获得“提交权限”到项目 GitHub 仓库而得到认可。总体上，所有项目决策都是通过核心开发者共识和社区输入来做出的。

虽然这种方法为我们服务良好，随着项目的发展，我们看到需要一个更正式的治理模型。SciPy 核心开发者表达了对包括 BDFL（终身仁慈独裁者）在内的领导模型的偏好。因此，未来该项目的领导将由一个 BDFL 和指导委员会组成。

BDFL

项目将有一个 BDFL（终身仁慈独裁者），目前是 Pauli Virtanen。作为独裁者，BDFL 有权为项目做出所有最终决策。作为仁慈的一面，BDFL 在实践中选择将这种权力推迟到社区讨论渠道和 Steering Council 的共识（见下文）。预计且过去确实如此，BDFL 很少会主张他/她的最终权力。由于很少被使用，我们将 BDFL 的最终权力称为“特别”或“优先”投票。当发生这种情况时，BDFL 的覆盖通常发生在 Steering Council 出现僵局或如果 Steering Council 要求 BDFL 在特定事项上做出决定的情况下。为确保 BDFL 的仁慈，项目鼓励其他人在不同意 BDFL 总体方向的情况下分叉项目。BDFL 可以根据自己的意愿将他/她在某个决定或一系列决策上的权力委派给任何其他理事会成员。

BDFL 可以任命他/她的继任者，但预期会在此决定上征求 Steering Council 的意见。如果 BDFL 无法任命继任者，则 Steering Council 将做出这一决定 - 最好是通过共识，但如果需要，也可以通过多数投票。

注意，BDFL 可以随时下台，并且会在诚信的前提下，听取有关下台的严肃呼吁。还要注意，BDFL 更多地是用于后备决策，而不是董事/首席执行官的角色。

Steering Council

项目将设有一个由项目贡献者组成的 Steering Council，这些贡献者在质量和数量上都有显著的贡献，并且这种贡献至少持续了一年。理事会的总体角色是通过与 BDFL 合作并接受社区的意见，确保项目的长期福祉，无论是在技术上还是作为一个社区。

理事会将有一名主席，负责保持理事会和项目运作的组织方面的顺利进行。理事会还将指定一个项目发布经理，对一个或多个版本的最终责任负责。

在日常项目活动中，理事会成员作为与所有其他贡献者和社区同等的伙伴参与所有讨论、代码审查和其他项目活动。在这些日常活动中，理事会成员不因其在理事会上的成员身份而享有任何特权或特权。然而，预计由于他们的贡献质量和数量以及他们对项目软件和服务的专业知识，理事会成员将为潜在经验较少的贡献者提供有用的技术指导和项目方向指导。

Steering Council 和其成员在某些情况下发挥特殊作用。具体来说，理事会可能会：

就项目的整体范围、愿景和方向做出决策。
就与其他组织或个人的战略合作做出决策。
就特定的技术问题、功能、错误和拉取请求做出决策。他们是引导代码审查过程和合并拉取请求的主要机制。
对由项目运行的服务做出决策，并为项目和社区的利益管理这些服务。
在常规社区讨论在合理时间内未能达成共识的问题上做出决策。
更新诸如此类的政策文件。

董事会成员资格

要成为董事会成员，个人必须是项目贡献者，其贡献在质量和数量上都相当可观，并且在至少一年的时间内保持持续性。潜在的董事会成员由现任董事会成员提名，并在询问潜在成员是否有兴趣和意愿担任该职位后，由现任董事会成员投票决定。董事会最初将由自 2017 年 1 月起在过去两年内显著活跃的现有核心开发者组成。

在考虑潜在成员时，董事会将综合考虑候选人的贡献。这将包括但不限于代码、代码审查、基础设施工作、邮件列表和聊天参与、社区帮助/建设、教育和推广、设计工作等。我们有意不设定任意的定量指标（如“在此存储库中有 100 次提交”），以避免鼓励仅追求指标而非项目整体健康的行为。我们希望在团队中鼓励多样化的背景、观点和才能，因此我们明确不将代码定义为评估董事会成员资格的唯一标准。

如果董事会成员在项目中处于一年的不活跃状态，将被考虑从董事会中删除。在删除之前，将与不活跃成员联系，看是否计划重新参与活跃。如果不计划重新参与，则将根据董事会投票立即将其删除。如果计划很快重新参与活跃，则将给予一年的宽限期。如果在此期限内不返回活跃状态，则将通过董事会投票将其移除，不再给予进一步的宽限期。所有前董事会成员可以随时再次被考虑成为未来的任何项目贡献者。退休的董事会成员将被列入项目网站，以承认其在董事会活跃期间的时段。

如果被认为对项目的健康状况有积极危害，并且沟通和冲突解决尝试失败，董事会保留将当前成员（除 BDFL 外）驱逐出局的权利。

当前 Steering Council 成员列表维护在关于我们页面。

理事会主席

主席将由 Steering Council 指定。主席可以任职任意时间，但可以随时辞职，并会认真考虑辞职的要求（类似于 BDFL 角色）。主席负责：

每年两次（约在四月中旬和十月中旬）开始审查项目的技术方向（如 SciPy Roadmap 中所述）。
在同一年的相同时间段，总结之前时期的任何相关组织更新和问题，并在邮件列表上征求反馈/建议。
确保 Steering Council 的成员组成保持最新状态。
确保 Steering Council 私下讨论的事项在邮件列表上得到总结，以保持社区的信息透明。
确保其他重要的组织文件（例如行为准则、财务赞助协议）在添加后保持最新状态。

发布经理

发布经理对发布承担最终责任。包括：

提议和决定发布时间。
在特定变更或功能上没有达成共识时，确定发布内容。
创建发布并在相关公共渠道宣布发布。

欲了解这些职责在实践中的具体内容，请参阅 SciPy 发布。

利益冲突

预计 BDFL 和理事会成员将受雇于各种公司、大学和非营利组织。因此，成员可能存在利益冲突。此类利益冲突包括但不限于：

财务利益，例如投资、就业或与项目外的合同工作，可能会影响他们在项目上的工作。
可能泄露到项目工作中的雇主专有信息的访问。

所有理事会成员，包括 BDFL 在内，应向理事会其余成员披露可能存在的利益冲突。在某个问题上存在利益冲突的成员可以参与讨论，但必须在投票时回避。如果 BDFL 在特定决策中回避自己，理事会将指定替代 BDFL 进行该决策。

理事会的私人通信

除非有特别要求，所有理事会的讨论和活动都将是公开的，并与项目贡献者和社区进行协作和讨论。理事会将有一个私人邮件列表，只在特定事项需要保密时才会适度使用。当需要私人沟通和决策时，理事会将尽最大努力在删除不应公开到公共互联网的个人/私人/敏感信息后向社区总结。

理事会决策制定

如果需要项目指导理事会做出正式决定，他们将采用一种Apache Foundation 投票过程的形式。这是共识的正式化版本，其中+1 代表同意，-1 代表否决（必须附上理由，如上所述），如果希望表达意见而不注册全面否决，也可以进行分数投票（例如-0.5、+0.5）。这些数字投票通常也被非正式地用作获取人们对某个问题的整体感觉的一种方式，通常不应视为正式投票。只有在明确声明的情况下才会进行正式投票，如果确实发生这种情况，则应该充分留出时间，以便所有感兴趣的理事会成员有机会回应，至少一周。

在实践中，我们预计对于大多数理事会决策（例如，选举新成员）将需要更为非正式的过程。

机构合作伙伴和资金

理事会是项目的主要领导机构。除了作为贡献者和理事会成员参与项目外，没有外部机构、个人或法律实体有能力拥有、控制、篡夺或影响项目。然而，由于机构可以是项目的重要资金机制，因此正式承认机构参与项目是很重要的。这些是机构合作伙伴。

机构贡献者是指作为其所属机构官方职责的一部分向项目做出贡献的个人项目贡献者。同样地，机构理事会成员是指作为其所属机构官方职责的一部分向项目做出贡献的项目指导理事会成员。

根据这些定义，机构合作伙伴是在任何国家都承认的法律实体，至少雇用了一个机构贡献者或机构理事会成员。机构合作伙伴可以是营利性或非营利性实体。

通过雇佣积极参与项目作为其官方职责的个人，机构可以成为机构合作伙伴。换句话说，合作伙伴影响项目的唯一方式是积极参与项目的开发，并与社区的其他贡献者和议会成员平等地发展项目。仅在机构环境中使用项目软件不能使实体成为机构合作伙伴。财政赠品不使实体能够成为机构合作伙伴。一旦机构有资格成为机构合作伙伴，指导委员会必须提名并批准合作伙伴关系。

如果某个现有的机构合作伙伴在某一时刻停止拥有任何贡献的雇员，那么将开始一个一年的宽限期。在这一年期满时，如果他们继续没有任何贡献的雇员，则他们的机构合作伙伴关系将失效，并且恢复将需要按照新合作伙伴关系的常规流程进行。

机构合作伙伴可以自由通过任何合法手段追求在项目上工作的资金。这可能涉及非营利组织从私人基金会和捐助者筹集资金，或营利公司构建利用项目软件和服务的专有产品和服务。机构合作伙伴为在项目上工作所获取的资金称为机构资金。然而，任何机构合作伙伴获得的资金都不能取代指导委员会的决定。如果合作伙伴有资金来进行 SciPy 工作，而议会决定不将其作为项目进行推进，合作伙伴可以自行进行。然而，在这种情况下，合作伙伴工作的那部分将不属于 SciPy 的范围，并且不能以任何方式使用项目商标表明正式关系。

机构合作伙伴的收益包括：

在 SciPy 网站和演讲中的承认
在 SciPy 网站和演讲中承认他们自己的资金来源的能力
通过其议会成员的参与影响项目的能力
议会成员受邀参加 SciPy 开发者会议

当前的机构合作伙伴列表可在页面关于我们上查看。

文档历史

github.com/scipy/scipy/commits/main/doc/source/dev/governance/governance.rst

致谢

本文档的大部分内容改编自Jupyter/IPython 项目的治理文档和NumPy 的治理文档。

许可证

根据CC-0 公共领域奉献/许可证，作者已尽可能放弃了 SciPy 项目治理文件的所有版权和相关或邻近权利。

发布说明

原文：docs.scipy.org/doc/scipy-1.12.0/release.html

这是 SciPy 每个版本之间的变更列表。要查看完整详情，请参见提交日志。

SciPy 1.12.0 发布说明
SciPy 1.11.4 发布说明
SciPy 1.11.3 发布说明
SciPy 1.11.2 发布说明
SciPy 1.11.1 发布说明
SciPy 1.11.0 发布说明
SciPy 1.10.1 发布说明
SciPy 1.10.0 发布说明
SciPy 1.9.3 发布说明
SciPy 1.9.2 发布说明
SciPy 1.9.1 发布说明
SciPy 1.9.0 发布说明
SciPy 1.8.1 发布说明
SciPy 1.8.0 发布说明
SciPy 1.7.3 发布说明
SciPy 1.7.2 发布说明
SciPy 1.7.1 发布说明
SciPy 1.7.0 发布说明
SciPy 1.6.3 发布说明
SciPy 1.6.2 发布说明
SciPy 1.6.1 发布说明
SciPy 1.6.0 发布说明
SciPy 1.5.4 发布说明
SciPy 1.5.3 发布说明
SciPy 1.5.2 发布说明
SciPy 1.5.1 发布说明
SciPy 1.5.0 发布说明
SciPy 1.4.1 发布说明
SciPy 1.4.0 发布说明
SciPy 1.3.3 发布说明
SciPy 1.3.2 发布说明
SciPy 1.3.1 发布说明
SciPy 1.3.0 发布说明
SciPy 1.2.3 发布说明
SciPy 1.2.2 发布说明
SciPy 1.2.1 发布说明
SciPy 1.2.0 发布说明
SciPy 1.1.0 发布说明
SciPy 1.0.1 发布说明
SciPy 1.0.0 发布说明
SciPy 0.19.1 发布说明
SciPy 0.19.0 发布说明
SciPy 0.18.1 发布说明
SciPy 0.18.0 发布说明
SciPy 0.17.1 发布说明
SciPy 0.17.0 发布说明
SciPy 0.16.1 发布说明
SciPy 0.16.0 发布说明
SciPy 0.15.1 发布说明
SciPy 0.15.0 发布说明
SciPy 0.14.1 发布说明
SciPy 0.14.0 发布说明
SciPy 0.13.2 发布说明
SciPy 0.13.1 发布说明
SciPy 0.13.0 发布说明
SciPy 0.12.1 发布说明
SciPy 0.12.0 发布说明
SciPy 0.11.0 发布说明
SciPy 0.10.1 发布说明
SciPy 0.10.0 发布说明
SciPy 0.9.0 发布说明
SciPy 0.8.0 发布说明
SciPy 0.7.2 发布说明
SciPy 0.7.1 发布说明
SciPy 0.7.0 发布说明

SciPy 1.12.0 发行说明

原文：docs.scipy.org/doc/scipy-1.12.0/release/1.12.0-notes.html

SciPy 1.12.0 发行说明
- 本次发行的亮点
- 新功能
  - scipy.cluster 改进
  - scipy.fft 改进
  - scipy.integrate 改进
  - scipy.interpolate 改进
  - scipy.linalg 改进
  - scipy.ndimage 改进
  - scipy.optimize 改进
  - scipy.signal 改进
  - scipy.sparse 改进
  - scipy.spatial 改进
  - scipy.special 改进
  - scipy.stats 改进
- 已弃用功能
- 过期的弃用功能
- 不兼容的后向变更
- 其他变更
- 作者
- 已关闭的问题 1.12.0
- 1.12.0 的拉取请求

SciPy 1.12.0 是六个月辛勤工作的成果。其中包含许多新功能、大量错误修复、改进的测试覆盖率和更好的文档。此版本中还有一些弃用和 API 变更，详细记录如下。建议所有用户升级到此版本，因为修复了大量错误并进行了优化。在升级之前，建议用户检查其代码是否使用了已弃用的 SciPy 功能（方法是使用 python -Wd 运行代码并检查 DeprecationWarning）。我们的开发重点现在将转移到 1.12.x 分支的错误修复版本和主分支上添加新功能。

本次发行需要 Python 3.9+ 和 NumPy 1.22.4 或更高版本。

为了在 PyPy 上运行，需要 PyPy3 6.0+。

本次发行的亮点

实验性支持数组 API 标准已添加到scipy.special的部分功能，以及所有scipy.fft和scipy.cluster。可能存在 bug，欢迎使用 CuPy 数组、PyTorch 张量和其他兼容数组 API 的库提供早期反馈。可通过设置SCIPY_ARRAY_API环境变量进行测试。
新的类ShortTimeFFT提供了短时傅里叶变换（STFT）、其逆变换（ISTFT）以及（交叉）谱图的更多功能实现。它采用了改进的算法来计算 ISTFT。
添加了几个稀疏数组的新构造函数，并且现在许多操作还支持稀疏数组，进一步促进了从稀疏矩阵的迁移。
大部分scipy.stats API 现在更好地支持处理NaN值、掩码数组和更精细的形状处理。改进了许多stats方法的准确性和性能，并添加了许多新的统计测试和分布。

新功能

`scipy.cluster` 的改进

实验性支持已添加到数组 API 标准；现在接受 PyTorch 张量、CuPy 数组和兼容数组 API 的数组库（GPU 支持仅限于具有纯 Python 实现的函数）。支持可以转换为 NumPy 的 CPU 数组，并且返回的数组将与输入类型匹配。在导入scipy之前设置SCIPY_ARRAY_API环境变量即可启用此行为。此实验性支持仍在开发中，可能包含 bug - 欢迎进行测试。

`scipy.fft` 的改进

实验性支持已添加到数组 API 标准；作为fft数组 API 标准扩展模块的一部分的函数，以及不在扩展模块中的快速 Hankel 变换和基本 FFT 现在接受 PyTorch 张量、CuPy 数组和兼容数组 API 的数组库。支持可以转换为 NumPy 数组的 CPU 数组，并且返回的数组将与输入类型匹配。在导入scipy之前设置SCIPY_ARRAY_API环境变量即可启用此行为。此实验性支持仍在开发中，可能包含 bug - 欢迎进行测试。

`scipy.integrate` 的改进

添加了 scipy.integrate.cumulative_simpson，用于使用辛普森 1/3 法则从采样数据计算累积积分。

`scipy.interpolate` 改进

新类 NdBSpline 表示 N 维张量积样条。该类只知道如何根据系数和结点向量评估张量积。这种方式将 BSpline 推广到 1D 数据到 N-D，与 NdPPoly 平行（表示 N-D 张量积多项式）。评估利用了 b 样条的局部化特性。
NearestNDInterpolator.__call__ 接受 **query_options 参数，这些参数会传递到 KDTree.query 调用中以查找最近邻。例如，可以通过 workers 关键字限制邻居搜索距离并并行化查询。
BarycentricInterpolator 现在允许计算导数。
现在可以在现有的 CloughTocher2DInterpolator 实例中更改插值点的插值值，同时还保存插值点的重心坐标。

`scipy.linalg` 改进

通过 dtgsyl 和 stgsyl 提供对新的低级 LAPACK 函数的访问。

`scipy.ndimage` 改进

`scipy.optimize` 改进

添加了 scipy.optimize.isotonic_regression 以允许非参数保序回归。
scipy.optimize.nnls 重写为 Python，并实现了所谓的 fnnls 或快速 nnls，使其在高维问题上更有效率。
scipy.optimize.root 和 scipy.optimize.root_scalar 的结果对象现在报告所使用的方法。
scipy.optimize.differential_evolution 的 callback 方法现在可以通过 intermediate_results 关键字参数传递更详细的信息。此外，进化策略现在接受一个可调用对象进行额外定制。differential_evolution 的性能也得到了改进。
scipy.optimize.minimize 方法 Newton-CG 现在支持返回稀疏 Hessian 矩阵/数组的函数作为 hess 参数，并且略微更有效。
scipy.optimize.minimize 方法 BFGS 现在接受 Hessian 逆的初始估计，这在某些情况下可以更高效地进行工作流程。新参数为 hess_inv0。
scipy.optimize.minimize 方法 CG、Newton-CG 和 BFGS 现在接受参数 c1 和 c2，允许指定 Armijo 和曲率规则参数。
scipy.optimize.curve_fit 由于对可调用函数的更有效的记忆化，性能有所提升。

`scipy.signal` 的改进

当 fs 有默认值时，freqz、freqz_zpk 和 group_delay 现在更加精确。
新的类 ShortTimeFFT 提供了短时傅里叶变换（STFT）的更多功能实现，包括其逆变换（ISTFT）以及（交叉）谱图。它利用改进的算法计算基于双窗口的 ISTFT，并在参数化方面提供了更精细的控制，特别是在缩放和相位移方面。增加了功能以便于处理信号和 STFT 块。在“SciPy 用户指南”中增加了一个章节，提供算法细节。函数 stft、istft 和 spectrogram 被标记为遗留功能。

`scipy.sparse` 的改进

sparse.linalg 迭代求解器 sparse.linalg.cg、sparse.linalg.cgs、sparse.linalg.bicg、sparse.linalg.bicgstab、sparse.linalg.gmres 和 sparse.linalg.qmr 现已用 Python 重写。
更新了内置的 SuperLU 版本至 6.0.1，并进行了一些额外的修复。
稀疏数组增加了额外的构造函数：eye_array、random_array、block_array 和 identity。kron 和 kronsum 已调整以支持在稀疏数组上的操作。
稀疏矩阵现在支持使用 axes=(1, 0) 进行转置，以镜像 .T 方法。
LaplacianNd 现在允许选择最大特征值的子集，并且额外支持检索对应的特征向量。LaplacianNd 的性能也得到了提升。
改进了 dok_matrix 和 dok_array 的性能，并且它们的继承行为应该更加健壮。
hstack、vstack 和 block_diag 现在可以处理稀疏数组，并保留输入的稀疏类型。
添加了一个新函数 scipy.sparse.linalg.matrix_power，允许对稀疏数组进行指数运算。

`scipy.spatial` 的改进

为 spatial.transform.Rotation 实现了两种新方法：__pow__ 用于将旋转提升到整数或分数幂次，以及 approx_equal 用于检查两个旋转是否近似相等。
方法 Rotation.align_vectors 已扩展为解决约束对齐问题，其中要求精确对齐两个向量。此外，当给定单个向量对时，算法现在返回最小幅度的旋转，这可以视为一个较小的不兼容性变更。
现在可以通过 from_davenport 和 as_davenport 方法获取 spatial.transform.Rotation 的一种新表示，称为 Davenport 角度。
对 distance.hamming 和 distance.correlation 进行了性能改进。
提升了 SphericalVoronoi 的性能，sort_vertices_of_regions 和二维区域计算。

`scipy.special` 的改进

添加了 scipy.special.stirling2 以计算第二类 Stirling 数。支持精确计算和渐近近似（默认）分别通过 exact=True 和 exact=False（默认）。
添加了 scipy.special.betaincc 用于计算互补不完全 Beta 函数和 scipy.special.betainccinv 用于计算其逆函数。
提高了 scipy.special.betainc 和 scipy.special.betaincinv 的精度。
已为备用后端添加实验性支持：函数scipy.special.log_ndtr，scipy.special.ndtr，scipy.special.ndtri，scipy.special.erf，scipy.special.erfc，scipy.special.i0，scipy.special.i0e，scipy.special.i1，scipy.special.i1e，scipy.special.gammaln，scipy.special.gammainc，scipy.special.gammaincc，scipy.special.logit，以及scipy.special.expit 现在支持 PyTorch 张量和 CuPy 数组。这些功能仍在开发中，可能存在错误，因此默认情况下已禁用；在导入 scipy 之前通过设置 SCIPY_ARRAY_API 环境变量为 1 启用它们。欢迎进行测试！

`scipy.stats` 改进

添加了 scipy.stats.quantile_test，用于非参数检验是否假设值为指定概率关联的分位数。结果对象的 confidence_interval 方法给出了分位数的置信区间。
scipy.stats.sampling.FastGeneratorInversion 提供了通过数值反演分布 CDF 快速进行随机抽样的便捷接口。
scipy.stats.geometric_discrepancy 添加了用于随机样本的几何/拓扑差异度量。
scipy.stats.multivariate_normal 现在具有 fit 方法，通过最大似然估计将分布参数拟合到数据中。
scipy.stats.bws_test 执行巴姆加特纳-韦斯-辛德勒测试，检验两个样本是否来自同一分布。
scipy.stats.jf_skew_t 实现了琼斯和法迪偏态-t 分布。
scipy.stats.anderson_ksamp 现在支持使用 method 参数进行置换版本的测试。
scipy.stats.halfcauchy、scipy.stats.halflogistic 和 scipy.stats.halfnorm 的 fit 方法更快且更精确。
scipy.stats.beta 对于分布参数的极端值，entropy 精度得到了提高。
对于多个分布，sf 和/或 isf 方法的精度得到了提高：scipy.stats.burr、scipy.stats.hypsecant、scipy.stats.kappa3、scipy.stats.loglaplace、scipy.stats.lognorm、scipy.stats.lomax、scipy.stats.pearson3、scipy.stats.rdist 和 scipy.stats.pareto。
现在，以下函数支持参数 axis、nan_policy 和 keep_dims：scipy.stats.entropy, scipy.stats.differential_entropy, scipy.stats.variation, scipy.stats.ansari, scipy.stats.bartlett, scipy.stats.levene, scipy.stats.fligner, scipy.stats.circmean, scipy.stats.circvar, scipy.stats.circstd, scipy.stats.tmean, scipy.stats.tvar, scipy.stats.tstd, scipy.stats.tmin, scipy.stats.tmax, 和 scipy.stats.tsem.
scipy.stats.skewnorm 的 logpdf 方法和 fit 方法已经得到了改善。
贝塔负二项分布的实现为 scipy.stats.betanbinom。
scipy.stats.invwishart 的 rvs 和 logpdf 的性能得到了改进。
在使用 method='mle' 时，scipy.stats.boxcox_normmax 中的中间溢出问题已被解决，并且 lmbda 的返回值受到约束，以确保转换后的数据不会溢出。
scipy.stats.nakagami stats 更加准确可靠。
消除了scipy.norminvgauss.pdf中的中间溢出源。
对scipy.stats.circmean、scipy.stats.circvar、scipy.stats.circstd和scipy.stats.entropy添加了对掩码数组的支持。
scipy.stats.dirichlet方法新增了一个协方差（cov）方法。
提高了scipy.stats.multivariate_t方法在大自由度下的熵方法的准确性。
scipy.stats.loggamma方法的熵计算方式得到了改进。

已弃用功能

对于不存在于公共命名空间中的对象，错误消息变得更加清晰，对于根本不应被导入的私有属性，警告也得到了加强。
scipy.signal.cmplx_sort已经被弃用，并将在 SciPy 1.15 版本中移除。您可以在弃用消息中找到可替代方案。
对scipy.integrate.cumulative_trapezoid中的参数initial，除了0和None之外的值已经弃用。
scipy.stats.rvs_ratio_uniforms已被弃用，推荐使用scipy.stats.sampling.RatioUniforms。
scipy.integrate.quadrature和scipy.integrate.romberg因准确性问题和接口缺陷已被弃用。它们将在 SciPy 1.15 版本中移除。请使用scipy.integrate.quad代替。
随着函数签名的即将更改（例如移除过时关键字），我们正在取消使用关键字参数的位置用法，这将从 SciPy 1.14 开始引发错误。在某些情况下，这延迟了最初宣布的移除日期，以便有时间应对第二部分弃用。受影响的函数包括：
- linalg.{eigh, eigvalsh, pinv}
- integrate.simpson
- signal.{firls, firwin, firwin2, remez}
- sparse.linalg.{bicg, bicgstab, cg, cgs, gcrotmk, gmres, lgmres, minres, qmr, tfqmr}
- special.comb
- stats.kendalltau
所有小波函数已弃用，PyWavelets 提供了合适的实现；受影响的函数有：signal.{daub, qmf, cascade, morlet, morlet2, ricker, cwt}
scipy.integrate.trapz, scipy.integrate.cumtrapz 和 scipy.integrate.simps 已弃用，改用 scipy.integrate.trapezoid, scipy.integrate.cumulative_trapezoid 和 scipy.integrate.simpson，并将在 SciPy 1.14 中移除。
scipy.sparse.linalg.{bcg, bicgstab, cg, cgs, gcrotmk, gmres, lgmres, minres, qmr, tfqmr} 的 tol 参数现已弃用，改用 rtol，并将在 SciPy 1.14 中移除。此外，这些函数的 atol 默认值将在 SciPy 1.14 中更改为 0.0。

过期弃用

正在努力完成长期弃用的工作。以下先前弃用的功能受到影响：

scipy.stats.qmc.LatinHypercube 的 centered 关键字已移除。使用 scrambled=False 替代 centered=True。
scipy.stats.binom_test 已移除，使用 scipy.stats.binomtest 替代。
在 scipy.stats.iqr 中，移除了使用 scale='raw' 的方式，改用 scale=1。