Ruff 类型检查器 ty 的命名空间包Namespace Package导入解析机制全解【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ru/ruff本文基于 Ruff 仓库中 ty 语义分析模块的导入测试文档 crates/ty_python_semantic/resources/mdtest/import/namespace.md 编写围绕 PEP 420 命名空间包在 ty 类型检查器中的解析规则展开。读者将掌握ty 如何区分常规包regular package与命名空间包、文件与同名命名空间包的优先级、from导入跨搜索路径的解析行为以及这些行为在源码中的实现依据。命名空间包Namespace Package是 PEP 420 定义的一种不包含__init__.py的包形态多个目录可以合并为同一个逻辑包。对于类型检查器而言命名空间包没有对应的代码文件因此其解析优先级、子模块发现方式都与常规包截然不同。tyRuff 内置的 Python 类型检查器通过 crates/ty_module_resolver 实现了对命名空间包的完整支持并用 markdown 测试文档固化了一系列行为契约。本文以该测试文档为主体逐节拆解其规则并给出源码级依据。一、测试文档的形态markdown 即测试用例在深入规则之前需要先理解这份文档的运行机制。namespace.md并非普通说明文档而是 ty 语义分析模块crates/ty_python_semantic的 mdtest 测试套件。其执行入口位于 crates/ruff_mdtest/src/lib.rs文档中的[environment]TOML 代码块会被解析为测试运行环境配置如python解释器路径、extra-paths额外搜索路径py代码块会被写入虚拟文件系统db.use_in_memory_system()项目根固定为/src作为被测源码代码块中以# error: [unresolved-import]注释标记预期诊断以reveal_type(...) # revealed: ...标记预期的类型推断结果最终由 crates/ruff_mdtest/src/db.rs 构建的 Salsa 数据库驱动测试执行并用matcher::match_file校验诊断与内联快照是否完全一致。因此本文中出现的每一个目录布局与代码示例都是 ty 的真实回归测试用例可直接用于验证或复现 ty 的导入解析行为。二、基础用例跨搜索路径合并的命名空间包文档的第一个用例演示了最典型的命名空间包场景——同一个逻辑包parent.child的两个子模块分别位于不同的搜索路径中[environment] python /.venvparent/child/one.pyone 1/.venv/path-to-site-packages/parent/child/two.pytwo 2main.pyimport parent.child.one import parent.child.twofrom.pyfrom parent.child import one, two reveal_type(one) # revealed: module parent.child.one reveal_type(two) # revealed: module parent.child.two该用例说明两个关键事实用户项目目录first-party 搜索路径与site-packages目录同时贡献了parent.child的目录片段两者合并为一个命名空间包from parent.child import one, two能够跨搜索路径解析出两个子模块且reveal_type能给出精确的模块类型module parent.child.one。源码依据Module枚举的两种形态在 crates/ty_module_resolver/src/module.rs 中ty 将模块解析结果建模为两种形态pub enum Moduledb { File(FileModuledb), Namespace(NamespacePackagedb), }其中NamespacePackage的注释明确说明了其特殊性见 module.rsNamespace packages are special because there are multiple possible paths and they have no corresponding code file.由于命名空间包没有对应文件Module::file()对命名空间包返回NoneModule::search_path()同样返回None因为命名空间包跨越多条搜索路径无法归属到单一搜索路径。这正是命名空间包天然低于常规包/模块优先级这一设计在数据类型层面的体现。三、命名空间包中的常规包__init__.py截断解析第二个用例是 PEP 420 嵌套命名空间包示例的改编PEP 420 Nested namespace packages[environment] python /.venvsrc parent child __init__.py one.py .venv/site-packages parent child two.pyparent/child/__init__.pyparent/child/one.pyone 1/.venv/path-to-site-packages/parent/child/two.pytwo 2main.pyimport parent.child.one import parent.child.two # error: [unresolved-import]这里的目录结构src/parent/child是常规包含__init__.py。文档明确断言site_packages/parent/child/two.py不应被解析即import parent.child.two必须报告[unresolved-import]。源码依据resolve_component的三级探测顺序该行为在 crates/ty_module_resolver/src/resolve.rs 的resolve_component中实现。解析模块名的每一个组成部分时按如下顺序探测常规包优先package_path.push(__init__)若存在__init__.py/__init__.pyi取决于ComponentFileFiltertyping 模式优先.pyi则判定为RegularPackage常规包见 resolve.rs文件模块次之若存在xxx.py/xxx.pyi判定为Module见 resolve.rs目录兜底以上均失败时若存在同名目录则判定为NamespacePackage见 resolve.rs。ModuleResolutionCandidate::missing_submodule_is_terminal()见 resolve.rs进一步明确常规包和文件模块都是终结候选——一个在更高优先级搜索路径上的foo.py或foo/__init__.py不会被低优先级搜索路径上的foo/__init__.py遮蔽且两者都会遮蔽命名空间包。因此当src中的parent/child被判定为常规包后搜索即终止site-packages下的同名目录不再参与合并parent.child.two自然无法解析。四、文件与同名命名空间包的优先级模块优先第三个用例揭示了一个易被忽略的细节——文件模块的优先级高于同名目录foo.pyx modulefoo/bar.pyx namespacefrom foo import x reveal_type(x) # revealed: Literal[module] import foo.bar # error: [unresolved-import]当foo.py与foo/目录同时存在时foo解析为foo.py文件模块而非foo/命名空间包目录因此from foo import x得到Literal[module]而import foo.bar因为文件模块无法包含子模块而报[unresolved-import]。源码依据normalize_candidates的剔除逻辑在 resolve.rs 的normalize_candidates中ty 会对同一模块名的多个候选进行归一化一旦存在非命名空间包RegularPackage或Module的同名候选命名空间包候选就会被直接丢弃tracing::trace!(Discarding namespace package ...)。这一剔除逻辑发生在最终组件解析时确保文件模块/常规包 命名空间包的优先级在任意搜索路径顺序下都成立。另外注意 resolve.rs 中的守卫ResolvedModule::Module(_)形态的候选单文件模块无法拥有子模块一旦命中即返回Err这正是foo.bar无法解析的另一个层面保证。五、from导入命名空间包回归用例 #363第四个用例是 astral-sh/ty#363 的回归测试模拟了真实第三方包的典型布局google/cloud/pubsub_v1/__init__.pyclass PublisherClient: ...from google.cloud import pubsub_v1 reveal_type(pubsub_v1.PublisherClient) # revealed: class PublisherClient该用例验证google、google.cloud均为命名空间包测试文档未给出它们的__init__.pypubsub_v1是其中的常规包。from google.cloud import pubsub_v1必须穿过两层命名空间包正确解析到pubsub_v1模块并让pubsub_v1.PublisherClient的类型被精确推断为class PublisherClient。这里涉及命名空间包解析的一个关键点当解析google.cloud.pubsub_v1时中间组件google、cloud是命名空间包无文件最终组件pubsub_v1才落到常规包__init__.py。ty 的resolve_remaining会逐组件推进期间命名空间包候选保留、但最终被具体包替换见 resolve.rs 与normalize_candidates中at the final component, a concrete package or module shadows it的注释。六、from根导入子包回归用例 #375第五个用例是 astral-sh/ty#375 的回归测试opentelemetry/trace/__init__.pyclass Trace: ...opentelemetry/metrics/__init__.pyclass Metric: ...from opentelemetry import trace, metrics reveal_type(trace) # revealed: module opentelemetry.trace reveal_type(metrics) # revealed: module opentelemetry.metricsopentelemetry是一个命名空间包无__init__.py其子包trace、metrics是常规包。from opentelemetry import trace, metrics一次性导入两个子包ty 必须分别解析opentelemetry.trace与opentelemetry.metrics并给出module opentelemetry.trace、module opentelemetry.metrics的模块类型。该用例与上一节共同验证了 ty 在from X import Y场景下的完整能力既支持Y 是命名空间包内的常规包也支持Y 是命名空间包的多个子包。其实现路径统一收敛到 resolve.rs 的resolve_module_for_import_from该函数从StmtImportFrom语句提取模块名后调用通用的resolve_module。七、跨搜索路径的优先级PEP 420 的全局规则最后一个大节是两个互为镜像的用例均为 astral-sh/ty#1749 的回归测试。文档开宗明义地给出了 PEP 420 的核心规则According PEP 420, namespace packages always have lower precedence than normal packages/modules, regardless of search path ordering.即命名空间包的优先级恒低于常规包/模块与搜索路径的先后顺序无关。场景一命名空间包在搜索路径前面[environment] extra-paths [/path-one, /path-two]/path-one/mod/sub1.py/path-two/mod/__init__.py/path-two/mod/sub2.pymain.pyimport mod import mod.sub1 # error: [unresolved-import] import mod.sub2/path-one排在前面其中的mod/是无__init__.py的命名空间包/path-two排在后面但其中的mod/__init__.py使mod成为常规包。结果mod解析为常规包mod.sub1报[unresolved-import]命名空间包贡献的sub1.py被常规包的终结性屏蔽mod.sub2正常解析。场景二命名空间包在搜索路径后面[environment] extra-paths [/path-two, /path-one]/path-one/mod/sub1.py/path-two/mod/__init__.py/path-two/mod/sub2.pymain.pyimport mod import mod.sub1 # error: [unresolved-import] import mod.sub2调换extra-paths顺序后结果完全一致mod.sub1依然报[unresolved-import]证明命名空间包优先级不依赖搜索路径顺序。源码依据终结候选的提前终止这两个用例的对称性正是discover_roots与resolve_remaining协作的结果在 resolve.rs 的discover_roots中ty 逐个遍历搜索路径收集候选一旦遇到终结候选terminal can_stop就break提前终止搜索之后的搜索路径不再贡献候选在 resolve.rs 的resolve_remaining中remaining_are_shadowed candidate.missing_submodule_is_terminal()会在命中终结候选后丢弃所有低优先级候选——即使该组件解析失败终结候选依然遮蔽其后的命名空间包。因此无论命名空间包出现在搜索路径的前面还是后面只要任一搜索路径中出现了同名常规包命名空间包的其余贡献就会被整体屏蔽。这也解释了为何两个场景得到相同的[unresolved-import]诊断。需要补充的是extra-paths配置即测试中的/path-one、/path-two在 crates/ty_module_resolver/src/path.rs 中对应SearchPath::extra属于SearchPathInner::Extra类别排在模块解析顺序的最前面见 path.rs 对搜索路径类型的文档注释。八、延伸legacy namespace package 与解析优先级全景与本文主题强相关、且同样位于同一测试目录的是 crates/ty_python_semantic/resources/mdtest/import/legacy_namespace.md它测试的是 PEP 420 之前生态的旧式命名空间包legacy namespace package包内含__path__ pkgutil.extend_path(__path__, __name__)或__import__(pkg_resources).declare_namespace(__name__)惯用写法。ty 对此类包的识别实现在 resolve.rs 的is_legacy_namespace_package与LegacyNamespacePackageVisitor——通过纯语法分析AST探测上述两种惯用表达式。旧式命名空间包在解析目标上按常规包处理见 resolve.rs 中LegacyNamespacePackage的注释这解释了其__version__等属性为何能被正常推断。结合本文各用例可以归纳 ty 的模块解析优先级全景typing 模式下PEP 561 stub 包package-stubs见 resolve.rs 的CandidatePrecedence::StubPackage优先级最高常规包/文件模块按搜索路径顺序比较且一旦命中即为终结候选命名空间包优先级恒最低不依赖搜索路径顺序PEP 420 规则。总结namespace.md用七组可执行的测试用例完整定义了 ty 对 PEP 420 命名空间包的解析语义跨搜索路径合并、常规包对命名空间包的截断、文件模块对同名命名空间包的遮蔽、from导入穿过命名空间包、以及命名空间包优先级恒低、与搜索路径顺序无关的全局规则。这些行为在 crates/ty_module_resolver/src/resolve.rs 的resolve_component、normalize_candidates、missing_submodule_is_terminal等核心函数中有清晰的实现对应。对于在真实项目中依赖命名空间包如google.cloud.*、opentelemetry.*等跨包布局的开发者而言理解上述优先级规则有助于准确预判 ty 报告的[unresolved-import]是否源于目录结构冲突并能据此调整包布局与extra-paths/src搜索路径配置。【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ru/ruff创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ruff 类型检查器 ty 的命名空间包（Namespace Package）导入解析机制全解
Ruff 类型检查器 ty 的命名空间包Namespace Package导入解析机制全解【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ru/ruff本文基于 Ruff 仓库中 ty 语义分析模块的导入测试文档 crates/ty_python_semantic/resources/mdtest/import/namespace.md 编写围绕 PEP 420 命名空间包在 ty 类型检查器中的解析规则展开。读者将掌握ty 如何区分常规包regular package与命名空间包、文件与同名命名空间包的优先级、from导入跨搜索路径的解析行为以及这些行为在源码中的实现依据。命名空间包Namespace Package是 PEP 420 定义的一种不包含__init__.py的包形态多个目录可以合并为同一个逻辑包。对于类型检查器而言命名空间包没有对应的代码文件因此其解析优先级、子模块发现方式都与常规包截然不同。tyRuff 内置的 Python 类型检查器通过 crates/ty_module_resolver 实现了对命名空间包的完整支持并用 markdown 测试文档固化了一系列行为契约。本文以该测试文档为主体逐节拆解其规则并给出源码级依据。一、测试文档的形态markdown 即测试用例在深入规则之前需要先理解这份文档的运行机制。namespace.md并非普通说明文档而是 ty 语义分析模块crates/ty_python_semantic的 mdtest 测试套件。其执行入口位于 crates/ruff_mdtest/src/lib.rs文档中的[environment]TOML 代码块会被解析为测试运行环境配置如python解释器路径、extra-paths额外搜索路径py代码块会被写入虚拟文件系统db.use_in_memory_system()项目根固定为/src作为被测源码代码块中以# error: [unresolved-import]注释标记预期诊断以reveal_type(...) # revealed: ...标记预期的类型推断结果最终由 crates/ruff_mdtest/src/db.rs 构建的 Salsa 数据库驱动测试执行并用matcher::match_file校验诊断与内联快照是否完全一致。因此本文中出现的每一个目录布局与代码示例都是 ty 的真实回归测试用例可直接用于验证或复现 ty 的导入解析行为。二、基础用例跨搜索路径合并的命名空间包文档的第一个用例演示了最典型的命名空间包场景——同一个逻辑包parent.child的两个子模块分别位于不同的搜索路径中[environment] python /.venvparent/child/one.pyone 1/.venv/path-to-site-packages/parent/child/two.pytwo 2main.pyimport parent.child.one import parent.child.twofrom.pyfrom parent.child import one, two reveal_type(one) # revealed: module parent.child.one reveal_type(two) # revealed: module parent.child.two该用例说明两个关键事实用户项目目录first-party 搜索路径与site-packages目录同时贡献了parent.child的目录片段两者合并为一个命名空间包from parent.child import one, two能够跨搜索路径解析出两个子模块且reveal_type能给出精确的模块类型module parent.child.one。源码依据Module枚举的两种形态在 crates/ty_module_resolver/src/module.rs 中ty 将模块解析结果建模为两种形态pub enum Moduledb { File(FileModuledb), Namespace(NamespacePackagedb), }其中NamespacePackage的注释明确说明了其特殊性见 module.rsNamespace packages are special because there are multiple possible paths and they have no corresponding code file.由于命名空间包没有对应文件Module::file()对命名空间包返回NoneModule::search_path()同样返回None因为命名空间包跨越多条搜索路径无法归属到单一搜索路径。这正是命名空间包天然低于常规包/模块优先级这一设计在数据类型层面的体现。三、命名空间包中的常规包__init__.py截断解析第二个用例是 PEP 420 嵌套命名空间包示例的改编PEP 420 Nested namespace packages[environment] python /.venvsrc parent child __init__.py one.py .venv/site-packages parent child two.pyparent/child/__init__.pyparent/child/one.pyone 1/.venv/path-to-site-packages/parent/child/two.pytwo 2main.pyimport parent.child.one import parent.child.two # error: [unresolved-import]这里的目录结构src/parent/child是常规包含__init__.py。文档明确断言site_packages/parent/child/two.py不应被解析即import parent.child.two必须报告[unresolved-import]。源码依据resolve_component的三级探测顺序该行为在 crates/ty_module_resolver/src/resolve.rs 的resolve_component中实现。解析模块名的每一个组成部分时按如下顺序探测常规包优先package_path.push(__init__)若存在__init__.py/__init__.pyi取决于ComponentFileFiltertyping 模式优先.pyi则判定为RegularPackage常规包见 resolve.rs文件模块次之若存在xxx.py/xxx.pyi判定为Module见 resolve.rs目录兜底以上均失败时若存在同名目录则判定为NamespacePackage见 resolve.rs。ModuleResolutionCandidate::missing_submodule_is_terminal()见 resolve.rs进一步明确常规包和文件模块都是终结候选——一个在更高优先级搜索路径上的foo.py或foo/__init__.py不会被低优先级搜索路径上的foo/__init__.py遮蔽且两者都会遮蔽命名空间包。因此当src中的parent/child被判定为常规包后搜索即终止site-packages下的同名目录不再参与合并parent.child.two自然无法解析。四、文件与同名命名空间包的优先级模块优先第三个用例揭示了一个易被忽略的细节——文件模块的优先级高于同名目录foo.pyx modulefoo/bar.pyx namespacefrom foo import x reveal_type(x) # revealed: Literal[module] import foo.bar # error: [unresolved-import]当foo.py与foo/目录同时存在时foo解析为foo.py文件模块而非foo/命名空间包目录因此from foo import x得到Literal[module]而import foo.bar因为文件模块无法包含子模块而报[unresolved-import]。源码依据normalize_candidates的剔除逻辑在 resolve.rs 的normalize_candidates中ty 会对同一模块名的多个候选进行归一化一旦存在非命名空间包RegularPackage或Module的同名候选命名空间包候选就会被直接丢弃tracing::trace!(Discarding namespace package ...)。这一剔除逻辑发生在最终组件解析时确保文件模块/常规包 命名空间包的优先级在任意搜索路径顺序下都成立。另外注意 resolve.rs 中的守卫ResolvedModule::Module(_)形态的候选单文件模块无法拥有子模块一旦命中即返回Err这正是foo.bar无法解析的另一个层面保证。五、from导入命名空间包回归用例 #363第四个用例是 astral-sh/ty#363 的回归测试模拟了真实第三方包的典型布局google/cloud/pubsub_v1/__init__.pyclass PublisherClient: ...from google.cloud import pubsub_v1 reveal_type(pubsub_v1.PublisherClient) # revealed: class PublisherClient该用例验证google、google.cloud均为命名空间包测试文档未给出它们的__init__.pypubsub_v1是其中的常规包。from google.cloud import pubsub_v1必须穿过两层命名空间包正确解析到pubsub_v1模块并让pubsub_v1.PublisherClient的类型被精确推断为class PublisherClient。这里涉及命名空间包解析的一个关键点当解析google.cloud.pubsub_v1时中间组件google、cloud是命名空间包无文件最终组件pubsub_v1才落到常规包__init__.py。ty 的resolve_remaining会逐组件推进期间命名空间包候选保留、但最终被具体包替换见 resolve.rs 与normalize_candidates中at the final component, a concrete package or module shadows it的注释。六、from根导入子包回归用例 #375第五个用例是 astral-sh/ty#375 的回归测试opentelemetry/trace/__init__.pyclass Trace: ...opentelemetry/metrics/__init__.pyclass Metric: ...from opentelemetry import trace, metrics reveal_type(trace) # revealed: module opentelemetry.trace reveal_type(metrics) # revealed: module opentelemetry.metricsopentelemetry是一个命名空间包无__init__.py其子包trace、metrics是常规包。from opentelemetry import trace, metrics一次性导入两个子包ty 必须分别解析opentelemetry.trace与opentelemetry.metrics并给出module opentelemetry.trace、module opentelemetry.metrics的模块类型。该用例与上一节共同验证了 ty 在from X import Y场景下的完整能力既支持Y 是命名空间包内的常规包也支持Y 是命名空间包的多个子包。其实现路径统一收敛到 resolve.rs 的resolve_module_for_import_from该函数从StmtImportFrom语句提取模块名后调用通用的resolve_module。七、跨搜索路径的优先级PEP 420 的全局规则最后一个大节是两个互为镜像的用例均为 astral-sh/ty#1749 的回归测试。文档开宗明义地给出了 PEP 420 的核心规则According PEP 420, namespace packages always have lower precedence than normal packages/modules, regardless of search path ordering.即命名空间包的优先级恒低于常规包/模块与搜索路径的先后顺序无关。场景一命名空间包在搜索路径前面[environment] extra-paths [/path-one, /path-two]/path-one/mod/sub1.py/path-two/mod/__init__.py/path-two/mod/sub2.pymain.pyimport mod import mod.sub1 # error: [unresolved-import] import mod.sub2/path-one排在前面其中的mod/是无__init__.py的命名空间包/path-two排在后面但其中的mod/__init__.py使mod成为常规包。结果mod解析为常规包mod.sub1报[unresolved-import]命名空间包贡献的sub1.py被常规包的终结性屏蔽mod.sub2正常解析。场景二命名空间包在搜索路径后面[environment] extra-paths [/path-two, /path-one]/path-one/mod/sub1.py/path-two/mod/__init__.py/path-two/mod/sub2.pymain.pyimport mod import mod.sub1 # error: [unresolved-import] import mod.sub2调换extra-paths顺序后结果完全一致mod.sub1依然报[unresolved-import]证明命名空间包优先级不依赖搜索路径顺序。源码依据终结候选的提前终止这两个用例的对称性正是discover_roots与resolve_remaining协作的结果在 resolve.rs 的discover_roots中ty 逐个遍历搜索路径收集候选一旦遇到终结候选terminal can_stop就break提前终止搜索之后的搜索路径不再贡献候选在 resolve.rs 的resolve_remaining中remaining_are_shadowed candidate.missing_submodule_is_terminal()会在命中终结候选后丢弃所有低优先级候选——即使该组件解析失败终结候选依然遮蔽其后的命名空间包。因此无论命名空间包出现在搜索路径的前面还是后面只要任一搜索路径中出现了同名常规包命名空间包的其余贡献就会被整体屏蔽。这也解释了为何两个场景得到相同的[unresolved-import]诊断。需要补充的是extra-paths配置即测试中的/path-one、/path-two在 crates/ty_module_resolver/src/path.rs 中对应SearchPath::extra属于SearchPathInner::Extra类别排在模块解析顺序的最前面见 path.rs 对搜索路径类型的文档注释。八、延伸legacy namespace package 与解析优先级全景与本文主题强相关、且同样位于同一测试目录的是 crates/ty_python_semantic/resources/mdtest/import/legacy_namespace.md它测试的是 PEP 420 之前生态的旧式命名空间包legacy namespace package包内含__path__ pkgutil.extend_path(__path__, __name__)或__import__(pkg_resources).declare_namespace(__name__)惯用写法。ty 对此类包的识别实现在 resolve.rs 的is_legacy_namespace_package与LegacyNamespacePackageVisitor——通过纯语法分析AST探测上述两种惯用表达式。旧式命名空间包在解析目标上按常规包处理见 resolve.rs 中LegacyNamespacePackage的注释这解释了其__version__等属性为何能被正常推断。结合本文各用例可以归纳 ty 的模块解析优先级全景typing 模式下PEP 561 stub 包package-stubs见 resolve.rs 的CandidatePrecedence::StubPackage优先级最高常规包/文件模块按搜索路径顺序比较且一旦命中即为终结候选命名空间包优先级恒最低不依赖搜索路径顺序PEP 420 规则。总结namespace.md用七组可执行的测试用例完整定义了 ty 对 PEP 420 命名空间包的解析语义跨搜索路径合并、常规包对命名空间包的截断、文件模块对同名命名空间包的遮蔽、from导入穿过命名空间包、以及命名空间包优先级恒低、与搜索路径顺序无关的全局规则。这些行为在 crates/ty_module_resolver/src/resolve.rs 的resolve_component、normalize_candidates、missing_submodule_is_terminal等核心函数中有清晰的实现对应。对于在真实项目中依赖命名空间包如google.cloud.*、opentelemetry.*等跨包布局的开发者而言理解上述优先级规则有助于准确预判 ty 报告的[unresolved-import]是否源于目录结构冲突并能据此调整包布局与extra-paths/src搜索路径配置。【免费下载链接】ruffAn extremely fast Python linter and code formatter, written in Rust.项目地址: https://gitcode.com/GitHub_Trending/ru/ruff创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考