数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载本文是 cuDFGPU DataFrame Library开发者指南的核心实践手册聚焦于仓库的目录组织约定、pre-commit 代码风格校验体系、API 弃用与移除的标准流程以及保持与 pandas API 对齐的兼容性策略。读完本文你将掌握在 cuDF 仓库中提交高质量代码所需的全套规范从理解 Cython 代码的存放位置、配置与运行 lint 工具到正确地标记弃用 API、编写兼容性测试再到处理与 pandas 行为差异的边界情况。一、概述cuDF 的贡献指南contributing_guide.md是一份面向开发者的高层实践概览与仓库根目录的 CONTRIBUTING.md 形成互补后者覆盖完整的贡献流程如使用 pre-commit 钩子、PR 提交流程而本文档专门讲解 cuDF 项目内部的工程约定——包括代码如何组织、如何保证风格一致、如何安全地弃用与移除 API以及如何维持与 pandas 的 API 兼容性。这些约定直接决定了 cuDF 这样一个横跨 Python、Cython、C/CUDA 多层技术栈的大型项目能否保持长期可维护性。二、目录结构与文件命名cuDF 的 Python 包在模块组织上刻意与 pandas 保持一致cuDF 大体上呈现出与 pandas 相同的可导入模块和子包结构。这意味着用户在使用cudf时可以沿用对pandas的认知习惯例如cudf.DataFrame、cudf.Series、cudf.api.types等从而降低迁移成本。在代码组织上指南明确了一条关键规则所有 Cython 代码都存放在python/cudf/cudf/_lib目录下。从当前仓库的实际结构看python/cudf/cudf/_lib/中包含 CMakeLists.txt、init.py 以及 strings_udf.pyx 等文件。这一约定有着清晰的工程动机构建隔离Cython 代码需要经过编译将其集中在_lib中便于 CMake 构建系统统一处理见 python/cudf/CMakeLists.txt避免与纯 Python 模块混淆分层清晰_lib层通常作为底层实现如字符串 UDF 等性能敏感的路径与上层 DataFrame 框架 API 之间的边界上层模块通过_lib暴露的接口间接调用编译后的实现工具链协同mypy 等静态检查工具在配置中显式排除cudf/_lib/见根目录 pyproject.toml 的[tool.mypy]配置因为 Cython 代码不适用纯 Python 的类型检查。从源码结构可以推断_lib目录随版本演进不断被 Cython/编译产物填充但所有 Cython 代码集中于此的约定始终是贡献者放置新.pyx/.pxd文件的首要依据。三、代码风格pre-commit 与多 linter 体系3.1 整体机制cuDF 通过pre-commit就是全部 lint 工具的配置入口。其配置策略是分层存放共享配置大多数 linter 的规则定义存放在根目录的pyproject.toml与其他 RAPIDS Python 项目共享cudf 特有扩展cuDF 专属的配置追加在python/cudf/pyproject.toml中。3.2 实际启用的钩子清单从 .pre-commit-config.yaml 的实际内容看cuDF 的钩子体系远比格式化 拼写检查丰富可以按用途分为以下几类通用文件检查pre-commit-hooks v6.0.0trailing-whitespace清除行尾空白end-of-file-fixer确保文件以换行符结尾check-xml校验 XML 文件格式。语言与格式钩子cython-lintMarcoGorelli/cython-lintCython 代码的 lint并固定依赖cython3.2.2,3.3.0a0mypypre-commit/mirrors-mypy对python/cudf/cudf、python/pylibcudf/pylibcudf、python/cudf_polars/cudf_polars等核心包做静态类型检查clang-formatpre-commit/mirrors-clang-format格式化 C/C/CUDA 代码ruff与ruff-formatastral-sh/ruff-pre-commitPython 代码 lint 与格式化规则定义在根目录pyproject.toml的[tool.ruff]段——例如行宽 79、目标 Python 版本 3.11并启用了E/F/W/I基础规则、D系列 docstring 规范、NPY002禁止np.random.seed等数百条规则numpydoc-validation强制python/cudf/cudf/下的 docstring 遵循 NumPy 文档规范cmake-format/cmake-lintCMake 文件格式化与 lintshellcheckShell 脚本静态检查。内容与元数据检查codespell拼写检查fix-smartquotestexthooks将智能引号替换为普通引号yamllintYAML 文件校验lycheeMarkdown 文档链接有效性检查本地/相对链接离线模式zizmorGitHub Actions 工作流安全审计。rapidsai/pre-commit-hooksRAPIDS 生态标准verify-copyright校验并自动修复 SPDX 版权头针对 cmake/cpp/cu/h/pxd/py/pyx 等各类型文件并为 brotli、bzip2、zlib、cxxopts 等第三方代码配置了不同的 SPDX 许可标识verify-dependencies/verify-alpha-spec/verify-codeowners/verify-hardcoded-version/verify-pyproject-license版本与依赖一致性检查rapids-dependency-file-generator根据dependencies.yaml自动生成各环境的依赖文件。本地自定义 pygrep 钩子最具 cuDF 特色local段定义了一批纯正则的门禁钩子它们直接编码了 cuDF 的工程决策例如钩子 ID作用匹配/排除模式no-deprecationwarning禁止引入DeprecationWarning统一使用FutureWarning匹配DeprecationWarning的使用但排除python/cudf/cudf/core/dtypes.py等少量仍需要它的文件no-programmatic-xfail禁止使用pytest.xfail匹配pytest.xfailuse-exec-policy-nosync强制使用rmm::exec_policy_nosync而非rmm::exec_policy匹配rmm::exec_policy(use-cuda-iterators强制使用 CUDA 迭代器替代等价 Thrust 迭代器匹配thrust::..._iteratoruse-cuda-memcpy-default强制使用cudaMemcpyDefault匹配显式cudaMemcpyHostToHost等use-cudf-memcpy-async强制使用cudf::detail::memcpy_async而非cudaMemcpyAsync匹配cudaMemcpyAsync并排除少数例外文件no-anonymous-namespaces-in-headers禁止在头文件中使用匿名命名空间遵循 C Core Guidelines SF.21匹配namespace {仅作用于cpp/include头文件no-unseeded-default-rng禁止未播种的default_rng()和np.random.seed匹配default_rng()/np.random.seedcudf-polars-ir-signatures校验 cudf-polars IR 的do_evaluate签名调用ci/check_cudf_polars_ir.py脚本doxygen-check校验cpp/include下的 Doxygen 文档调用ci/checks/doxygen.sh这些本地钩子体现了一个重要原则用自动化强制替代人工 review。凡是团队反复在 review 中强调的规范都会被固化为 pygrep 钩子确保任何 PR 都无法漏网。此外配置中还通过ci.autofix_commit_msg声明了 pre-commit.ci 自动提交信息并在ci.skip中列明 mypy、verify-alpha-spec、verify-dependencies、lychee 等钩子不在 CI 自动运行例如 lychee 的钩子脚本在 pre-commit.ci 的克隆环境中执行git rev-parse会失败因此改由ci/check_style.sh通过pre-commit run --all-files运行。四、弃用Deprecating与移除Removing代码4.1 整体策略提前一个发布周期cuDF 遵循**弃用一个版本随后移除**的策略例如如果决定在 22.08 发布周期移除某个 API那么它会在 22.08 版本中被标记为 deprecated并在 22.10 版本中正式移除。这里有一个重要的补充规则如果代码注释中明确写了类似# Do not remove until..的条件那么在注释中的条件满足之前不得强制执行弃用即不得删除受影响代码。这通常用于处理那些依赖外部生态如 pandas 版本升级、其他 RAPIDS 库才能移除的 API。4.2 实施弃用时Implementing a Deprecation的检查清单当需要标记一个 API 为弃用时必须同时完成以下四件事移除并替换 cuDF 内部对该弃用 API 的所有内部使用——确保仓库自身不再依赖即将淘汰的接口在文档中使用 Sphinxdeprecated指令描述弃用——即在 docstring 中加入.. deprecated::块使用warnings.warn抛出FutureWarning并附上描述弃用信息的消息消息必须满足由单行组成不能包含换行符指明替代 API如果有不要指定未来某个具体版本即不写将在 25.02 移除这种话因为移除时间可能变化添加一个单元测试验证该警告确实会触发。原文档给出的完整弃用示例mock 性质如下import warnings def foo(self): Return a result from foo .. deprecated:: 23.08 foo is deprecated and will be removed in a future version of cudf. warnings.warn( Series.foo is deprecated and will be removed in a future version of cudf. Use Series.new_foo instead., FutureWarning )注意示例中的细节docstring 里的.. deprecated:: 23.08指明弃用起始版本warnings.warn的消息提示了替代 APISeries.new_foo且未承诺具体移除版本。4.3 强制执行弃用Enforcing a Deprecation时的检查清单当弃用周期结束、正式移除 API 时需要同步清理三处删除 API 的实现删除python/cudf/cudf/tests下关联的测试删除docs/cudf文档中的相关引用。4.4 仓库中的真实印证上述策略在仓库中是可验证的弃用警告统一使用FutureWarning。例如 python/cudf/cudf/io/feather.py 中read_feather/to_feather会抛出warnings.warn(...)未指定 category 时默认UserWarning而正式弃用路径均使用FutureWarning类别测试端通过pytest.warns(FutureWarning)来验证弃用警告确实触发。例如 python/cudf/cudf/tests/reshape/test_stack.py 中with pytest.warns(FutureWarning): got gdf.stack(levellevel, dropnadropna, future_stackFalse)以及 python/cudf/cudf/tests/general_functions/test_to_datetime.py 同样使用pytest.warns(FutureWarning)断言弃用警告。本地钩子no-deprecationwarning见 .pre-commit-config.yaml从源头禁止新增DeprecationWarning因为DeprecationWarning默认对用户不可见会静默丢失弃用信息确保弃用提示对用户真正可见——这正是弃用必须用FutureWarning的自动化保障。五、pandas 兼容性pandas Compatibility5.1 对齐原则cuDF 的 API 签名与行为应当与 pandas API 对齐。虽然 cuDF 可能支持一个范围内的多个 pandas 版本但API 签名和行为始终与最新支持的 pandas 版本对齐。这意味着贡献者在设计新 API 或修改现有 API 时应以当前最新支持的 pandas 版本为基准进行对照。5.2 允许偏离 pandas 的常见原因指南明确列出了四类允许有意识偏离 pandas 行为的情况偏离原因说明性能Performance若完全匹配 pandas 行为会带来过高exorbitant的运行时或内存成本可以偏离。此类偏离必须经 cuDF 开发者共同同意即不能由单个贡献者自行决定数据类型表示Data type representationscuDF 与 pandas 都未完整支持对方的类型系统常见于object类型或嵌套类型nested types异常消息Exception messagescuDF 抛出的异常类型应与 pandas 一致但错误消息文本无需逐字对齐警告Warnings对于镜像 pandas 的 APIcuDF 通常应匹配其警告行为但由于两个库之间存在有意差异部分警告可能不适用5.3 有意偏差必须文档化任何有意的行为偏差都应记录在pandas 对比pandas comparison章节中见 documentation.md 的 Comparing to pandas 一节。根据 documentation.md 的补充说明具体做法是当 API 在签名或行为上有意偏离 pandas 时在 API 的 docstring 内部使用自定义的pandas-compatSphinx 指令来描述差异例如def foo(self): Returns result from foo. .. pandas-compat:: :meth:pandas.DataFrame.foo Explanation of differences 所有与 pandas 的 API 兼容性差异最终都会渲染到 pandas 对比PandasCompat.md页面形成一份机器可读、面向用户的差异清单。5.4 完全无法匹配时的兜底NotImplementedError如果某个 pandas API或其中的特定组件完全无法匹配那么它应当抛出NotImplementedError。这保证了用户能够明确感知cuDF 暂不支持该功能而不是在行为偏差中静默地得到错误结果。5.5 抑制来自依赖的警告最后一个细节是依赖警告的处理如果 cuDF 的某个 API 会触发来自 cuDF 依赖项的警告且无法在 API 内部合理解决则使用warnings.catch_warnings将该警告从用户视角抑制掉。python/cudf/cudf/io/feather.py 给出了实际范例——当 PyArrow 24 起pyarrow.feather模块本身被标记 deprecated 时cuDF 在调用feather.read_table前用catch_warningsfilterwarnings(ignore, ...)屏蔽了来自 pyarrow 的FutureWarning避免把依赖方的弃用噪音泄露给 cuDF 用户with warnings.catch_warnings(): warnings.filterwarnings( ignore, messagerpyarrow\.feather\.read_table is deprecated, categoryFutureWarning, ) pa_table feather.read_table(path, *args, **kwargs)这一模式是cuDF 自己的 API 应匹配 pandas 的警告行为但依赖链上的噪音不应暴露给用户这一原则的直接落地。六、实战建议与自检清单综合上述规范一位 cuDF 贡献者在提交 PR 前可以按以下清单自检代码位置新写的 Cython 代码是否放在了python/cudf/cudf/_lib纯 Python API 是否与 pandas 模块结构对齐风格检查本地是否运行过pre-commit run --all-files确保所有钩子含自定义 pygrep 钩子通过尤其关注no-deprecationwarning、no-unseeded-default-rng、use-cuda-iterators等 cuDF 专属门禁。弃用流程若在弃用 API——是否同步替换了内部使用、补充了.. deprecated::docstring、抛出单行FutureWarning消息、并添加了pytest.warns(FutureWarning)测试若在移除 API——是否同步清理了实现、python/cudf/cudf/tests下的测试和docs/cudf中的文档pandas 对齐新 API 是否与最新支持的 pandas 版本对齐若有偏差是否属于性能、类型表示、异常消息、警告四类允许范围性能类偏差是否已与 cuDF 开发者达成一致偏差是否通过pandas-compat指令记录在 docstring 中异常与警告无法匹配的 API 是否抛出了NotImplementedError依赖产生的警告是否用warnings.catch_warnings抑制遵循这些约定既能保证 cuDF 与 pandas 生态的无缝衔接也能让大规模、跨语言Python/Cython/CUDA的代码库长期保持风格统一与演进可控。赞分享数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载相关推荐10 分钟把 360P 老视频免费升到 4KVideo2X 视频超分辨率入门教程10 分钟把 360P 老视频免费升到 4KVideo2X 视频超分辨率入门教程 Video2X 是一个免费开源的视频超分辨率与补帧框架它能把你手里 360音视频视频处理图像处理深度学习efinance 项目贡献指南代码结构与开发规范详解efinance 项目贡献指南代码结构与开发规范详解 efinance 是一个强大的开源金融数据获取工具库专为量化交易和数据分析设计。作为想要参与开源贡献的金融科技数据分析网页爬虫游戏文件压缩革命用tochd工具将ISO转换为CHD格式节省40%存储空间游戏文件压缩革命用tochd工具将ISO转换为CHD格式节省40%存储空间 在数字游戏收藏日益庞大的今天模拟器玩家们面临着一个共同的难题海量的游戏镜像文件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 cuDF 贡献指南：目录结构、代码规范、弃用策略与 pandas 兼容性全解析
数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载本文是 cuDFGPU DataFrame Library开发者指南的核心实践手册聚焦于仓库的目录组织约定、pre-commit 代码风格校验体系、API 弃用与移除的标准流程以及保持与 pandas API 对齐的兼容性策略。读完本文你将掌握在 cuDF 仓库中提交高质量代码所需的全套规范从理解 Cython 代码的存放位置、配置与运行 lint 工具到正确地标记弃用 API、编写兼容性测试再到处理与 pandas 行为差异的边界情况。一、概述cuDF 的贡献指南contributing_guide.md是一份面向开发者的高层实践概览与仓库根目录的 CONTRIBUTING.md 形成互补后者覆盖完整的贡献流程如使用 pre-commit 钩子、PR 提交流程而本文档专门讲解 cuDF 项目内部的工程约定——包括代码如何组织、如何保证风格一致、如何安全地弃用与移除 API以及如何维持与 pandas 的 API 兼容性。这些约定直接决定了 cuDF 这样一个横跨 Python、Cython、C/CUDA 多层技术栈的大型项目能否保持长期可维护性。二、目录结构与文件命名cuDF 的 Python 包在模块组织上刻意与 pandas 保持一致cuDF 大体上呈现出与 pandas 相同的可导入模块和子包结构。这意味着用户在使用cudf时可以沿用对pandas的认知习惯例如cudf.DataFrame、cudf.Series、cudf.api.types等从而降低迁移成本。在代码组织上指南明确了一条关键规则所有 Cython 代码都存放在python/cudf/cudf/_lib目录下。从当前仓库的实际结构看python/cudf/cudf/_lib/中包含 CMakeLists.txt、init.py 以及 strings_udf.pyx 等文件。这一约定有着清晰的工程动机构建隔离Cython 代码需要经过编译将其集中在_lib中便于 CMake 构建系统统一处理见 python/cudf/CMakeLists.txt避免与纯 Python 模块混淆分层清晰_lib层通常作为底层实现如字符串 UDF 等性能敏感的路径与上层 DataFrame 框架 API 之间的边界上层模块通过_lib暴露的接口间接调用编译后的实现工具链协同mypy 等静态检查工具在配置中显式排除cudf/_lib/见根目录 pyproject.toml 的[tool.mypy]配置因为 Cython 代码不适用纯 Python 的类型检查。从源码结构可以推断_lib目录随版本演进不断被 Cython/编译产物填充但所有 Cython 代码集中于此的约定始终是贡献者放置新.pyx/.pxd文件的首要依据。三、代码风格pre-commit 与多 linter 体系3.1 整体机制cuDF 通过pre-commit就是全部 lint 工具的配置入口。其配置策略是分层存放共享配置大多数 linter 的规则定义存放在根目录的pyproject.toml与其他 RAPIDS Python 项目共享cudf 特有扩展cuDF 专属的配置追加在python/cudf/pyproject.toml中。3.2 实际启用的钩子清单从 .pre-commit-config.yaml 的实际内容看cuDF 的钩子体系远比格式化 拼写检查丰富可以按用途分为以下几类通用文件检查pre-commit-hooks v6.0.0trailing-whitespace清除行尾空白end-of-file-fixer确保文件以换行符结尾check-xml校验 XML 文件格式。语言与格式钩子cython-lintMarcoGorelli/cython-lintCython 代码的 lint并固定依赖cython3.2.2,3.3.0a0mypypre-commit/mirrors-mypy对python/cudf/cudf、python/pylibcudf/pylibcudf、python/cudf_polars/cudf_polars等核心包做静态类型检查clang-formatpre-commit/mirrors-clang-format格式化 C/C/CUDA 代码ruff与ruff-formatastral-sh/ruff-pre-commitPython 代码 lint 与格式化规则定义在根目录pyproject.toml的[tool.ruff]段——例如行宽 79、目标 Python 版本 3.11并启用了E/F/W/I基础规则、D系列 docstring 规范、NPY002禁止np.random.seed等数百条规则numpydoc-validation强制python/cudf/cudf/下的 docstring 遵循 NumPy 文档规范cmake-format/cmake-lintCMake 文件格式化与 lintshellcheckShell 脚本静态检查。内容与元数据检查codespell拼写检查fix-smartquotestexthooks将智能引号替换为普通引号yamllintYAML 文件校验lycheeMarkdown 文档链接有效性检查本地/相对链接离线模式zizmorGitHub Actions 工作流安全审计。rapidsai/pre-commit-hooksRAPIDS 生态标准verify-copyright校验并自动修复 SPDX 版权头针对 cmake/cpp/cu/h/pxd/py/pyx 等各类型文件并为 brotli、bzip2、zlib、cxxopts 等第三方代码配置了不同的 SPDX 许可标识verify-dependencies/verify-alpha-spec/verify-codeowners/verify-hardcoded-version/verify-pyproject-license版本与依赖一致性检查rapids-dependency-file-generator根据dependencies.yaml自动生成各环境的依赖文件。本地自定义 pygrep 钩子最具 cuDF 特色local段定义了一批纯正则的门禁钩子它们直接编码了 cuDF 的工程决策例如钩子 ID作用匹配/排除模式no-deprecationwarning禁止引入DeprecationWarning统一使用FutureWarning匹配DeprecationWarning的使用但排除python/cudf/cudf/core/dtypes.py等少量仍需要它的文件no-programmatic-xfail禁止使用pytest.xfail匹配pytest.xfailuse-exec-policy-nosync强制使用rmm::exec_policy_nosync而非rmm::exec_policy匹配rmm::exec_policy(use-cuda-iterators强制使用 CUDA 迭代器替代等价 Thrust 迭代器匹配thrust::..._iteratoruse-cuda-memcpy-default强制使用cudaMemcpyDefault匹配显式cudaMemcpyHostToHost等use-cudf-memcpy-async强制使用cudf::detail::memcpy_async而非cudaMemcpyAsync匹配cudaMemcpyAsync并排除少数例外文件no-anonymous-namespaces-in-headers禁止在头文件中使用匿名命名空间遵循 C Core Guidelines SF.21匹配namespace {仅作用于cpp/include头文件no-unseeded-default-rng禁止未播种的default_rng()和np.random.seed匹配default_rng()/np.random.seedcudf-polars-ir-signatures校验 cudf-polars IR 的do_evaluate签名调用ci/check_cudf_polars_ir.py脚本doxygen-check校验cpp/include下的 Doxygen 文档调用ci/checks/doxygen.sh这些本地钩子体现了一个重要原则用自动化强制替代人工 review。凡是团队反复在 review 中强调的规范都会被固化为 pygrep 钩子确保任何 PR 都无法漏网。此外配置中还通过ci.autofix_commit_msg声明了 pre-commit.ci 自动提交信息并在ci.skip中列明 mypy、verify-alpha-spec、verify-dependencies、lychee 等钩子不在 CI 自动运行例如 lychee 的钩子脚本在 pre-commit.ci 的克隆环境中执行git rev-parse会失败因此改由ci/check_style.sh通过pre-commit run --all-files运行。四、弃用Deprecating与移除Removing代码4.1 整体策略提前一个发布周期cuDF 遵循**弃用一个版本随后移除**的策略例如如果决定在 22.08 发布周期移除某个 API那么它会在 22.08 版本中被标记为 deprecated并在 22.10 版本中正式移除。这里有一个重要的补充规则如果代码注释中明确写了类似# Do not remove until..的条件那么在注释中的条件满足之前不得强制执行弃用即不得删除受影响代码。这通常用于处理那些依赖外部生态如 pandas 版本升级、其他 RAPIDS 库才能移除的 API。4.2 实施弃用时Implementing a Deprecation的检查清单当需要标记一个 API 为弃用时必须同时完成以下四件事移除并替换 cuDF 内部对该弃用 API 的所有内部使用——确保仓库自身不再依赖即将淘汰的接口在文档中使用 Sphinxdeprecated指令描述弃用——即在 docstring 中加入.. deprecated::块使用warnings.warn抛出FutureWarning并附上描述弃用信息的消息消息必须满足由单行组成不能包含换行符指明替代 API如果有不要指定未来某个具体版本即不写将在 25.02 移除这种话因为移除时间可能变化添加一个单元测试验证该警告确实会触发。原文档给出的完整弃用示例mock 性质如下import warnings def foo(self): Return a result from foo .. deprecated:: 23.08 foo is deprecated and will be removed in a future version of cudf. warnings.warn( Series.foo is deprecated and will be removed in a future version of cudf. Use Series.new_foo instead., FutureWarning )注意示例中的细节docstring 里的.. deprecated:: 23.08指明弃用起始版本warnings.warn的消息提示了替代 APISeries.new_foo且未承诺具体移除版本。4.3 强制执行弃用Enforcing a Deprecation时的检查清单当弃用周期结束、正式移除 API 时需要同步清理三处删除 API 的实现删除python/cudf/cudf/tests下关联的测试删除docs/cudf文档中的相关引用。4.4 仓库中的真实印证上述策略在仓库中是可验证的弃用警告统一使用FutureWarning。例如 python/cudf/cudf/io/feather.py 中read_feather/to_feather会抛出warnings.warn(...)未指定 category 时默认UserWarning而正式弃用路径均使用FutureWarning类别测试端通过pytest.warns(FutureWarning)来验证弃用警告确实触发。例如 python/cudf/cudf/tests/reshape/test_stack.py 中with pytest.warns(FutureWarning): got gdf.stack(levellevel, dropnadropna, future_stackFalse)以及 python/cudf/cudf/tests/general_functions/test_to_datetime.py 同样使用pytest.warns(FutureWarning)断言弃用警告。本地钩子no-deprecationwarning见 .pre-commit-config.yaml从源头禁止新增DeprecationWarning因为DeprecationWarning默认对用户不可见会静默丢失弃用信息确保弃用提示对用户真正可见——这正是弃用必须用FutureWarning的自动化保障。五、pandas 兼容性pandas Compatibility5.1 对齐原则cuDF 的 API 签名与行为应当与 pandas API 对齐。虽然 cuDF 可能支持一个范围内的多个 pandas 版本但API 签名和行为始终与最新支持的 pandas 版本对齐。这意味着贡献者在设计新 API 或修改现有 API 时应以当前最新支持的 pandas 版本为基准进行对照。5.2 允许偏离 pandas 的常见原因指南明确列出了四类允许有意识偏离 pandas 行为的情况偏离原因说明性能Performance若完全匹配 pandas 行为会带来过高exorbitant的运行时或内存成本可以偏离。此类偏离必须经 cuDF 开发者共同同意即不能由单个贡献者自行决定数据类型表示Data type representationscuDF 与 pandas 都未完整支持对方的类型系统常见于object类型或嵌套类型nested types异常消息Exception messagescuDF 抛出的异常类型应与 pandas 一致但错误消息文本无需逐字对齐警告Warnings对于镜像 pandas 的 APIcuDF 通常应匹配其警告行为但由于两个库之间存在有意差异部分警告可能不适用5.3 有意偏差必须文档化任何有意的行为偏差都应记录在pandas 对比pandas comparison章节中见 documentation.md 的 Comparing to pandas 一节。根据 documentation.md 的补充说明具体做法是当 API 在签名或行为上有意偏离 pandas 时在 API 的 docstring 内部使用自定义的pandas-compatSphinx 指令来描述差异例如def foo(self): Returns result from foo. .. pandas-compat:: :meth:pandas.DataFrame.foo Explanation of differences 所有与 pandas 的 API 兼容性差异最终都会渲染到 pandas 对比PandasCompat.md页面形成一份机器可读、面向用户的差异清单。5.4 完全无法匹配时的兜底NotImplementedError如果某个 pandas API或其中的特定组件完全无法匹配那么它应当抛出NotImplementedError。这保证了用户能够明确感知cuDF 暂不支持该功能而不是在行为偏差中静默地得到错误结果。5.5 抑制来自依赖的警告最后一个细节是依赖警告的处理如果 cuDF 的某个 API 会触发来自 cuDF 依赖项的警告且无法在 API 内部合理解决则使用warnings.catch_warnings将该警告从用户视角抑制掉。python/cudf/cudf/io/feather.py 给出了实际范例——当 PyArrow 24 起pyarrow.feather模块本身被标记 deprecated 时cuDF 在调用feather.read_table前用catch_warningsfilterwarnings(ignore, ...)屏蔽了来自 pyarrow 的FutureWarning避免把依赖方的弃用噪音泄露给 cuDF 用户with warnings.catch_warnings(): warnings.filterwarnings( ignore, messagerpyarrow\.feather\.read_table is deprecated, categoryFutureWarning, ) pa_table feather.read_table(path, *args, **kwargs)这一模式是cuDF 自己的 API 应匹配 pandas 的警告行为但依赖链上的噪音不应暴露给用户这一原则的直接落地。六、实战建议与自检清单综合上述规范一位 cuDF 贡献者在提交 PR 前可以按以下清单自检代码位置新写的 Cython 代码是否放在了python/cudf/cudf/_lib纯 Python API 是否与 pandas 模块结构对齐风格检查本地是否运行过pre-commit run --all-files确保所有钩子含自定义 pygrep 钩子通过尤其关注no-deprecationwarning、no-unseeded-default-rng、use-cuda-iterators等 cuDF 专属门禁。弃用流程若在弃用 API——是否同步替换了内部使用、补充了.. deprecated::docstring、抛出单行FutureWarning消息、并添加了pytest.warns(FutureWarning)测试若在移除 API——是否同步清理了实现、python/cudf/cudf/tests下的测试和docs/cudf中的文档pandas 对齐新 API 是否与最新支持的 pandas 版本对齐若有偏差是否属于性能、类型表示、异常消息、警告四类允许范围性能类偏差是否已与 cuDF 开发者达成一致偏差是否通过pandas-compat指令记录在 docstring 中异常与警告无法匹配的 API 是否抛出了NotImplementedError依赖产生的警告是否用warnings.catch_warnings抑制遵循这些约定既能保证 cuDF 与 pandas 生态的无缝衔接也能让大规模、跨语言Python/Cython/CUDA的代码库长期保持风格统一与演进可控。赞分享数据分析数据工程机器学习【免费下载链接】cudfcuDF - GPU DataFrame Library项目地址https://gitcode.com/gh_mirrors/cu/cudf点击查看免费下载相关推荐10 分钟把 360P 老视频免费升到 4KVideo2X 视频超分辨率入门教程10 分钟把 360P 老视频免费升到 4KVideo2X 视频超分辨率入门教程 Video2X 是一个免费开源的视频超分辨率与补帧框架它能把你手里 360音视频视频处理图像处理深度学习efinance 项目贡献指南代码结构与开发规范详解efinance 项目贡献指南代码结构与开发规范详解 efinance 是一个强大的开源金融数据获取工具库专为量化交易和数据分析设计。作为想要参与开源贡献的金融科技数据分析网页爬虫游戏文件压缩革命用tochd工具将ISO转换为CHD格式节省40%存储空间游戏文件压缩革命用tochd工具将ISO转换为CHD格式节省40%存储空间 在数字游戏收藏日益庞大的今天模拟器玩家们面临着一个共同的难题海量的游戏镜像文件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考