TheAlgorithms/Python 贡献指南详解编写可测试、带类型标注且能通过自动化 CI 的算法实现【免费下载链接】PythonAll Algorithms implemented in Python项目地址: https://gitcode.com/GitHub_Trending/pyt/Python本文以 CONTRIBUTING.md 为核心系统讲解 TheAlgorithms/Python 算法库对贡献者的完整要求什么样的代码才算一个合格的“算法”、必须满足哪些命名、docstring、doctest 与类型标注规范以及 pre-commit、ruff、mypy、pytest 等自动化工具链如何逐层拦截不合规的提交。读完本文你可以按仓库实际执行的验证标准写出一次就能通过 CI 的 PR。一、贡献前必须确认的三件事仓库欢迎实现算法与数据结构的新贡献者但要求提交者在发起 pull request 之前完整阅读贡献指南对指南本身有疑义时应通过 issue 明确说明原文档中的 issue 入口、Gitter 社区链接属于外部社区页面此处不再罗列。成为贡献者即表示确认以下三点代码为本人独立完成不抄袭——任何抄袭作品不会被合并提交的工作在 PR 合并后将以 MIT License 分发对应仓库根目录的 LICENSE.md提交内容满足或基本满足仓库的编码风格与标准。关于“做什么”的边界指南划得很清楚欢迎全新实现同一问题的新解法、图数据结构的另一种表示、复杂度不同的算法设计不允许对已有实现的完全相同复制。提交前必须先自查该解法是否已经存在可检索目录导航 DIRECTORY.md改进注释、补写规范测试同样是高价值贡献与实现复杂算法同等被欢迎。二、仓库对“算法”的操作性定义这是贡献前最关键的判定标准。仓库认为一个算法是一或多个函数或类它应当接收一个或多个输入执行内部计算或数据操作返回一个或多个输出副作用最小化如print()、plot()、read()、write()都应避免。进一步地算法应满足以下八条要求类名与函数名直观读者一眼能看懂用途遵循 Python 命名约定变量名直觉化灵活地接受不同的输入值输入参数与返回值带 Python 类型标注type hints对错误输入抛出 Python 异常如ValueError带 docstring清晰解释算法或给出来源资料链接包含覆盖合法输入与错误输入的 doctest返回计算结果而不是打印或绘图。指南还特别强调仓库中的算法不应是现成 Python 第三方库的 how-to 示例而应自己完成把输入转换为输出的计算可以使用第三方库的数据类型、类或函数但每个算法必须提供独特价值。这条规则解释了为什么仓库的maths/、sorts/等目录下的实现几乎都是纯计算逻辑。三、本地自动化第一道关卡pre-commit指南建议使用 pre-commit 钩子在每次 commit 时自动按仓库风格修正代码python3 -m pip install pre-commit # 仅首次需要 pre-commit install安装后插件会在每次 commit 时运行如发现问题修复后再提交。也可以手动对全部文件强制执行pre-commit run --all-files --show-diff-on-failure当前仓库的 .pre-commit-config.yaml 给出了这套钩子的完整清单可作为“提交前会被检查什么”的权威参照pre-commit-hookscheck-toml、check-yaml、end-of-file-fixer仅 Python 文件、trailing-whitespace、check-executables-have-shebangs、requirements-txt-fixerauto-walrus自动简化海象运算符写法astral-sh/ruff-pre-commitruff-check与ruff-format两个钩子即 lint 与格式化codespell拼写检查词表与跳过规则配置在 pyproject.toml 的[tool.codespell]段pyproject-fmt与validate-pyproject保持pyproject.toml格式与合法性local 钩子validate-filenames直接执行 scripts/validate_filenames.pyprettier对 TOML/YAML 文件做格式化。其中validate-filenames钩子把指南中“文件名严格使用 snake_case”的要求变成了硬校验。从 scripts/validate_filenames.py 的源码看它会遍历所有合法文件路径逐一检测大写字母、空格、连字符以及未放入目录的散文件任一违规即以非零退出码终止钩子。这正是指南第 7 节“strictly use snake_case”的机器实现。四、编码风格命名、版本、格式化与 Lint4.1 Python 版本基线指南正文写的是“请使用 Python 3.13”例如print Hello已不可用必须print(Hello)。需要注意当前仓库的实际情况已经前进pyproject.toml 声明requires-python 3.14ruff 的target-version py314、mypy 的python_version 3.14均以 3.14 为准CI 工作流 .github/workflows/build.yml 中setup-python安装的也是 3.14。也就是说文档写 3.13 是下限要求而当前仓库代码与 CI 的实际运行基线是 Python 3.14新提交建议直接按 3.14 的语法能力来写。4.2 命名规范高度重视函数、类、变量命名用描述性名称替代冗余注释避免单字母变量名除非其生命周期只有几行缩写要展开gcd()难以理解而greatest_common_divisor()不会遵循 Python 命名约定变量与函数用小写下划线lower_case常量全大写UPPERCASE类名 CamelCase。这一条与 ruff 的Npep8-naming规则组直接对应pyproject.toml 的lint.select启用了N、PL等命名相关规则组。4.3 字符串格式化、black 与 ruff鼓励在能提升可读性时使用 f-string建议在提交前用 PSF 的black格式化指南说明其尚非强制但能自动对齐 PEP 8 的多数要求python3 -m pip install black # 仅首次需要 black .所有提交必须通过ruff检查才会被接受因此务必在本地先跑python3 -m pip install ruff # 仅首次需要 ruff check当前仓库的 ruff 配置远比默认严格pyproject.toml 中lint.select启用了约 40 个规则组涵盖FPyflakes、E/Wpycodestyle、Bbugbear、Sbandit 安全、SIM简化、UPpyupgrade、N命名、Iisort等同时按注释显式保留了一批“暂不修复”的规则如S101允许assert与 doctest 风格兼容。此外还有若干量化上限例如 McCabe 圈复杂度上限被放宽到 17lint.mccabe.max-complexity 17pylint.max-branches 20。另有独立工作流 .github/workflows/ruff.yml 在 CI 中执行 ruff与指南“All submissions will need to pass the testruff .”相互印证。4.4 docstring 与注释的合格线原创代码提交必须带 docstring 或注释说明工作内容若参考了 Wikipedia 等来源请把 URL 写进 docstring 或注释帮助读者溯源.github/pull_request_template.md 的清单也要求“所有新算法至少包含一个指向 Wikipedia 或类似解释页面的 URL”过细的注释会被打回例如x x 2 # increased by 2这种注释过于琐碎注释应当有解释价值且位置行上/行尾/行下在同一代码块内保持一致。指南给出的 docstring 正例注意缩进def sum_ab(a, b): Return the sum of two integers a and b. return a b4.5 doctest被 pytest 自动采集的文档测试指南强烈建议所有函数都写 doctest并给出完整示例def sum_ab(a, b): Return the sum of two integers a and b sum_ab(2, 2) 4 sum_ab(-2, 3) 1 sum_ab(4.9, 5.1) 10.0 return a b这些 doctest 会被 pytest 作为自动化测试的一部分运行因此提交前应在本地确认它们能被发现并通过python3 -m doctest -v my_submission.py这条要求并非空话。从 pyproject.toml 的 pytest 配置看ini_options.addopts中全局启用了--doctest-modules意味着 pytest 对每个模块都会执行 doctest 收集.github/workflows/build.yml 的测试步骤正是uv run --withpytest-run-parallel pytest ... --cov. .doctest 失败等同于 CI 失败。同时 PR 模板明确要求“All functions have doctests that pass the automated testing”。4.6 input() 的使用约束内置input()不鼓励使用尤其禁止input eval(input(...))这类危险写法input(Enter your input:) # Or even worse... input eval(input(Enter your input: ))如果确需input()应优雅处理首尾空白追加.strip()starting_value int(input(Please enter a starting value: ).strip())4.7 类型标注与 mypy建议为函数参数与返回值添加类型标注因为自动化测试会运行 mypydef sum_ab(a: int, b: int) - int: return a b本地检查命令mypy --ignore-missing-imports . # 测试所有文件 mypy --ignore-missing-imports path/to/file.py # 测试单个文件pyproject.toml 中[tool.mypy]将python_version固定为3.14。需要说明的现状是当前 .pre-commit-config.yaml 中的 mypy 钩子处于注释状态但指南仍将 mypy 列为提交前必查项PR 模板也把“所有函数参数与返回值带类型标注”列入检查清单因此本地手动跑 mypy 仍是实际要求。4.8 其他风格条款列表推导式与生成器优先于lambda、map、filter、reduce但核心是展示易读易维护的 Python基础算法避免引入外部库复杂算法才允许使用第三方库指南原文要求“需要requirements.txt中不存在的第三方模块时请把它加入该文件”。对照当前仓库实际状态根目录已不存在requirements.txt依赖改由 pyproject.toml 的dependencies声明并用 uv.lock 锁定CI 通过uv sync --grouptest安装。因此新增依赖的正确做法是在pyproject.toml中声明并更新锁文件。五、Issue 工作流不指派、不占坑、用 Fixes # 自动关闭指南对 issue 的处理方式有三条硬规则想解决某个 open issue直接提交带修复方案的 PR 即可——本仓库不指派 issue不要请求许可不要为“想贡献某个算法”而开 issue应直接提 PR为保持 issue 列表精简解决某个 issue 的 PR 必须在描述中写入关闭关键字。例如 PR 修复 issue #10则描述中加入Fixes #10GitHub 会在 PR 合并时据此自动关闭该 issue。.github/pull_request_template.md 的最后一条检查项也要求 PR 描述包含Fixes #ISSUE-NUMBER形式的关闭关键字两者口径一致。六、其余提交要求目录、命名与自动生成文件向project_euler/目录提交代码前必须先阅读该目录的专门指南 project_euler/README.md代码文件扩展名必须是.pyJupyter Notebook 不归本仓库收录文件名严格使用 snake_case下划线分隔便于脚本解析——如前所述这一条由validate-filenames钩子机器强制尽量避免新建目录优先把代码放入现有目录结构并跟随目标文件夹内部已有的惯例修改/新增代码后提交前确认代码可编译运行修改/新增文档则要求语言简洁、无语法错误不要手动更新 README.md 或 DIRECTORY.md——两者由 GitHub Actions 定期自动生成。从源码可印证.github/workflows/build.yml 在测试成功后执行scripts/build_directory_md.py 21 | tee DIRECTORY.md由 scripts/build_directory_md.py 重建目录导航所有提交都会被 mypy 测试鼓励在有意义处添加类型标注指南最后强调提交时请始终一致地遵守这些准则。七、这些要求如何被 CI 与运维脚本实际执行把 CONTRIBUTING.md 的条款放回仓库基础设施中可以看到一条完整的“文档—工具—CI—运维”闭环pytest 主测试流.github/workflows/build.yml 在ubuntu-latest上安装 Python 3.14、用 uv 同步test依赖组后以pytest-run-parallel并行执行全仓测试--doctest-modules由 pyproject.toml 全局开启并附--cov覆盖率报告同时--ignore掉若干依赖网络或重模型的例外文件如web_programming/current_stock_price.py、machine_learning/lstm/lstm_prediction.py、project_euler/等。这正是指南所说“提交后在 PR 页面底部观察 Actions 测试、失败时点 details 查看输出”的测试来源。ruff 独立工作流.github/workflows/ruff.yml 单独保证 lint 关卡。PR 模板即验收清单.github/pull_request_template.md 把“原创声明、单一 PR 只改一个算法文件、文件放入现有目录、全小写无空格无连字符的文件名、命名规范、类型标注、doctest 通过、含 Wikipedia 链接、Fixes # 关键字”全部显式列成 checkbox与本文各节条款一一对应。超量 PR 的批量清理维护者还依据 CONTRIBUTING.md 的硬性标准编写了运维脚本。从 scripts/README.md 看close_pull_requests_with_require_tests.sh、close_pull_requests_with_require_type_hints.sh、close_pull_requests_with_require_descriptive_names.sh、close_pull_requests_with_failing_tests.sh等脚本用于关闭不满足“测试、类型标注、描述性命名”要求的 PR——这解释了为什么指南中 doctest 与 type hints 不是建议而是准入门槛。八、小结一份可直接执行的提交前检查清单综合 CONTRIBUTING.md 全文与仓库工具链现状一次合格的提交前应完成确认解法不与现有实现重复且代码放在现有目录中文件名全小写 snake_case无空格、连字符或大写validate-filenames会拦截函数/类命名描述化参数与返回值带类型标注错误输入抛异常每个函数写 docstring含来源 URL与覆盖正误输入的 doctest并本地跑python3 -m doctest -v file验证本地执行pre-commit run --all-files --show-diff-on-failure保证 ruff check/format、拼写与 TOML/YAML 检查全部通过本地执行ruff check与mypy --ignore-missing-imports file若解决 issue在 PR 描述写入Fixes #N不要改动 README.md / DIRECTORY.md不要新建目录。按这条清单提交你的 PR 就能与 pyproject.toml、.pre-commit-config.yaml 和 .github/workflows/build.yml 所定义的验证体系完整对齐一次通过自动化测试。【免费下载链接】PythonAll Algorithms implemented in Python项目地址: https://gitcode.com/GitHub_Trending/pyt/Python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
TheAlgorithms/Python 贡献指南详解编写可测试、带类型标注且能通过自动化 CI 的算法实现【免费下载链接】PythonAll Algorithms implemented in Python项目地址: https://gitcode.com/GitHub_Trending/pyt/Python本文以 CONTRIBUTING.md 为核心系统讲解 TheAlgorithms/Python 算法库对贡献者的完整要求什么样的代码才算一个合格的“算法”、必须满足哪些命名、docstring、doctest 与类型标注规范以及 pre-commit、ruff、mypy、pytest 等自动化工具链如何逐层拦截不合规的提交。读完本文你可以按仓库实际执行的验证标准写出一次就能通过 CI 的 PR。一、贡献前必须确认的三件事仓库欢迎实现算法与数据结构的新贡献者但要求提交者在发起 pull request 之前完整阅读贡献指南对指南本身有疑义时应通过 issue 明确说明原文档中的 issue 入口、Gitter 社区链接属于外部社区页面此处不再罗列。成为贡献者即表示确认以下三点代码为本人独立完成不抄袭——任何抄袭作品不会被合并提交的工作在 PR 合并后将以 MIT License 分发对应仓库根目录的 LICENSE.md提交内容满足或基本满足仓库的编码风格与标准。关于“做什么”的边界指南划得很清楚欢迎全新实现同一问题的新解法、图数据结构的另一种表示、复杂度不同的算法设计不允许对已有实现的完全相同复制。提交前必须先自查该解法是否已经存在可检索目录导航 DIRECTORY.md改进注释、补写规范测试同样是高价值贡献与实现复杂算法同等被欢迎。二、仓库对“算法”的操作性定义这是贡献前最关键的判定标准。仓库认为一个算法是一或多个函数或类它应当接收一个或多个输入执行内部计算或数据操作返回一个或多个输出副作用最小化如print()、plot()、read()、write()都应避免。进一步地算法应满足以下八条要求类名与函数名直观读者一眼能看懂用途遵循 Python 命名约定变量名直觉化灵活地接受不同的输入值输入参数与返回值带 Python 类型标注type hints对错误输入抛出 Python 异常如ValueError带 docstring清晰解释算法或给出来源资料链接包含覆盖合法输入与错误输入的 doctest返回计算结果而不是打印或绘图。指南还特别强调仓库中的算法不应是现成 Python 第三方库的 how-to 示例而应自己完成把输入转换为输出的计算可以使用第三方库的数据类型、类或函数但每个算法必须提供独特价值。这条规则解释了为什么仓库的maths/、sorts/等目录下的实现几乎都是纯计算逻辑。三、本地自动化第一道关卡pre-commit指南建议使用 pre-commit 钩子在每次 commit 时自动按仓库风格修正代码python3 -m pip install pre-commit # 仅首次需要 pre-commit install安装后插件会在每次 commit 时运行如发现问题修复后再提交。也可以手动对全部文件强制执行pre-commit run --all-files --show-diff-on-failure当前仓库的 .pre-commit-config.yaml 给出了这套钩子的完整清单可作为“提交前会被检查什么”的权威参照pre-commit-hookscheck-toml、check-yaml、end-of-file-fixer仅 Python 文件、trailing-whitespace、check-executables-have-shebangs、requirements-txt-fixerauto-walrus自动简化海象运算符写法astral-sh/ruff-pre-commitruff-check与ruff-format两个钩子即 lint 与格式化codespell拼写检查词表与跳过规则配置在 pyproject.toml 的[tool.codespell]段pyproject-fmt与validate-pyproject保持pyproject.toml格式与合法性local 钩子validate-filenames直接执行 scripts/validate_filenames.pyprettier对 TOML/YAML 文件做格式化。其中validate-filenames钩子把指南中“文件名严格使用 snake_case”的要求变成了硬校验。从 scripts/validate_filenames.py 的源码看它会遍历所有合法文件路径逐一检测大写字母、空格、连字符以及未放入目录的散文件任一违规即以非零退出码终止钩子。这正是指南第 7 节“strictly use snake_case”的机器实现。四、编码风格命名、版本、格式化与 Lint4.1 Python 版本基线指南正文写的是“请使用 Python 3.13”例如print Hello已不可用必须print(Hello)。需要注意当前仓库的实际情况已经前进pyproject.toml 声明requires-python 3.14ruff 的target-version py314、mypy 的python_version 3.14均以 3.14 为准CI 工作流 .github/workflows/build.yml 中setup-python安装的也是 3.14。也就是说文档写 3.13 是下限要求而当前仓库代码与 CI 的实际运行基线是 Python 3.14新提交建议直接按 3.14 的语法能力来写。4.2 命名规范高度重视函数、类、变量命名用描述性名称替代冗余注释避免单字母变量名除非其生命周期只有几行缩写要展开gcd()难以理解而greatest_common_divisor()不会遵循 Python 命名约定变量与函数用小写下划线lower_case常量全大写UPPERCASE类名 CamelCase。这一条与 ruff 的Npep8-naming规则组直接对应pyproject.toml 的lint.select启用了N、PL等命名相关规则组。4.3 字符串格式化、black 与 ruff鼓励在能提升可读性时使用 f-string建议在提交前用 PSF 的black格式化指南说明其尚非强制但能自动对齐 PEP 8 的多数要求python3 -m pip install black # 仅首次需要 black .所有提交必须通过ruff检查才会被接受因此务必在本地先跑python3 -m pip install ruff # 仅首次需要 ruff check当前仓库的 ruff 配置远比默认严格pyproject.toml 中lint.select启用了约 40 个规则组涵盖FPyflakes、E/Wpycodestyle、Bbugbear、Sbandit 安全、SIM简化、UPpyupgrade、N命名、Iisort等同时按注释显式保留了一批“暂不修复”的规则如S101允许assert与 doctest 风格兼容。此外还有若干量化上限例如 McCabe 圈复杂度上限被放宽到 17lint.mccabe.max-complexity 17pylint.max-branches 20。另有独立工作流 .github/workflows/ruff.yml 在 CI 中执行 ruff与指南“All submissions will need to pass the testruff .”相互印证。4.4 docstring 与注释的合格线原创代码提交必须带 docstring 或注释说明工作内容若参考了 Wikipedia 等来源请把 URL 写进 docstring 或注释帮助读者溯源.github/pull_request_template.md 的清单也要求“所有新算法至少包含一个指向 Wikipedia 或类似解释页面的 URL”过细的注释会被打回例如x x 2 # increased by 2这种注释过于琐碎注释应当有解释价值且位置行上/行尾/行下在同一代码块内保持一致。指南给出的 docstring 正例注意缩进def sum_ab(a, b): Return the sum of two integers a and b. return a b4.5 doctest被 pytest 自动采集的文档测试指南强烈建议所有函数都写 doctest并给出完整示例def sum_ab(a, b): Return the sum of two integers a and b sum_ab(2, 2) 4 sum_ab(-2, 3) 1 sum_ab(4.9, 5.1) 10.0 return a b这些 doctest 会被 pytest 作为自动化测试的一部分运行因此提交前应在本地确认它们能被发现并通过python3 -m doctest -v my_submission.py这条要求并非空话。从 pyproject.toml 的 pytest 配置看ini_options.addopts中全局启用了--doctest-modules意味着 pytest 对每个模块都会执行 doctest 收集.github/workflows/build.yml 的测试步骤正是uv run --withpytest-run-parallel pytest ... --cov. .doctest 失败等同于 CI 失败。同时 PR 模板明确要求“All functions have doctests that pass the automated testing”。4.6 input() 的使用约束内置input()不鼓励使用尤其禁止input eval(input(...))这类危险写法input(Enter your input:) # Or even worse... input eval(input(Enter your input: ))如果确需input()应优雅处理首尾空白追加.strip()starting_value int(input(Please enter a starting value: ).strip())4.7 类型标注与 mypy建议为函数参数与返回值添加类型标注因为自动化测试会运行 mypydef sum_ab(a: int, b: int) - int: return a b本地检查命令mypy --ignore-missing-imports . # 测试所有文件 mypy --ignore-missing-imports path/to/file.py # 测试单个文件pyproject.toml 中[tool.mypy]将python_version固定为3.14。需要说明的现状是当前 .pre-commit-config.yaml 中的 mypy 钩子处于注释状态但指南仍将 mypy 列为提交前必查项PR 模板也把“所有函数参数与返回值带类型标注”列入检查清单因此本地手动跑 mypy 仍是实际要求。4.8 其他风格条款列表推导式与生成器优先于lambda、map、filter、reduce但核心是展示易读易维护的 Python基础算法避免引入外部库复杂算法才允许使用第三方库指南原文要求“需要requirements.txt中不存在的第三方模块时请把它加入该文件”。对照当前仓库实际状态根目录已不存在requirements.txt依赖改由 pyproject.toml 的dependencies声明并用 uv.lock 锁定CI 通过uv sync --grouptest安装。因此新增依赖的正确做法是在pyproject.toml中声明并更新锁文件。五、Issue 工作流不指派、不占坑、用 Fixes # 自动关闭指南对 issue 的处理方式有三条硬规则想解决某个 open issue直接提交带修复方案的 PR 即可——本仓库不指派 issue不要请求许可不要为“想贡献某个算法”而开 issue应直接提 PR为保持 issue 列表精简解决某个 issue 的 PR 必须在描述中写入关闭关键字。例如 PR 修复 issue #10则描述中加入Fixes #10GitHub 会在 PR 合并时据此自动关闭该 issue。.github/pull_request_template.md 的最后一条检查项也要求 PR 描述包含Fixes #ISSUE-NUMBER形式的关闭关键字两者口径一致。六、其余提交要求目录、命名与自动生成文件向project_euler/目录提交代码前必须先阅读该目录的专门指南 project_euler/README.md代码文件扩展名必须是.pyJupyter Notebook 不归本仓库收录文件名严格使用 snake_case下划线分隔便于脚本解析——如前所述这一条由validate-filenames钩子机器强制尽量避免新建目录优先把代码放入现有目录结构并跟随目标文件夹内部已有的惯例修改/新增代码后提交前确认代码可编译运行修改/新增文档则要求语言简洁、无语法错误不要手动更新 README.md 或 DIRECTORY.md——两者由 GitHub Actions 定期自动生成。从源码可印证.github/workflows/build.yml 在测试成功后执行scripts/build_directory_md.py 21 | tee DIRECTORY.md由 scripts/build_directory_md.py 重建目录导航所有提交都会被 mypy 测试鼓励在有意义处添加类型标注指南最后强调提交时请始终一致地遵守这些准则。七、这些要求如何被 CI 与运维脚本实际执行把 CONTRIBUTING.md 的条款放回仓库基础设施中可以看到一条完整的“文档—工具—CI—运维”闭环pytest 主测试流.github/workflows/build.yml 在ubuntu-latest上安装 Python 3.14、用 uv 同步test依赖组后以pytest-run-parallel并行执行全仓测试--doctest-modules由 pyproject.toml 全局开启并附--cov覆盖率报告同时--ignore掉若干依赖网络或重模型的例外文件如web_programming/current_stock_price.py、machine_learning/lstm/lstm_prediction.py、project_euler/等。这正是指南所说“提交后在 PR 页面底部观察 Actions 测试、失败时点 details 查看输出”的测试来源。ruff 独立工作流.github/workflows/ruff.yml 单独保证 lint 关卡。PR 模板即验收清单.github/pull_request_template.md 把“原创声明、单一 PR 只改一个算法文件、文件放入现有目录、全小写无空格无连字符的文件名、命名规范、类型标注、doctest 通过、含 Wikipedia 链接、Fixes # 关键字”全部显式列成 checkbox与本文各节条款一一对应。超量 PR 的批量清理维护者还依据 CONTRIBUTING.md 的硬性标准编写了运维脚本。从 scripts/README.md 看close_pull_requests_with_require_tests.sh、close_pull_requests_with_require_type_hints.sh、close_pull_requests_with_require_descriptive_names.sh、close_pull_requests_with_failing_tests.sh等脚本用于关闭不满足“测试、类型标注、描述性命名”要求的 PR——这解释了为什么指南中 doctest 与 type hints 不是建议而是准入门槛。八、小结一份可直接执行的提交前检查清单综合 CONTRIBUTING.md 全文与仓库工具链现状一次合格的提交前应完成确认解法不与现有实现重复且代码放在现有目录中文件名全小写 snake_case无空格、连字符或大写validate-filenames会拦截函数/类命名描述化参数与返回值带类型标注错误输入抛异常每个函数写 docstring含来源 URL与覆盖正误输入的 doctest并本地跑python3 -m doctest -v file验证本地执行pre-commit run --all-files --show-diff-on-failure保证 ruff check/format、拼写与 TOML/YAML 检查全部通过本地执行ruff check与mypy --ignore-missing-imports file若解决 issue在 PR 描述写入Fixes #N不要改动 README.md / DIRECTORY.md不要新建目录。按这条清单提交你的 PR 就能与 pyproject.toml、.pre-commit-config.yaml 和 .github/workflows/build.yml 所定义的验证体系完整对齐一次通过自动化测试。【免费下载链接】PythonAll Algorithms implemented in Python项目地址: https://gitcode.com/GitHub_Trending/pyt/Python创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
