未排序的 dunder slots (RUF023)

有时提供修复。

作用

检查未按自然排序排列的 __slots__ 定义。

为什么这不好？

一致性是有益的。对于此特殊变量使用统一的规范，可以使您的代码更具可读性和惯用性。

示例

class Dog:
    __slots__ = "name", "breed"

建议改为

class Dog:
    __slots__ = "breed", "name"

修复安全性

本规则的自动修复在以下三种情况下被标记为不安全。

首先，如果 __slots__ 定义内部存在独占一行的注释（例如：），则修复被视为不安全。

class Foo:
    __slots__ = [
        # eggy things
        "duck_eggs",
        "chicken_eggs",
        # hammy things
        "country_ham",
        "parma_ham",
    ]

这是一种常用于分隔类插槽（slots）类别的模式，但在对 __slots__ 项目进行自然排序时，尝试维护这些类别超出了本规则的范畴。

其次，如果单行上有超过两个 __slots__ 项目，且该行包含行尾注释，修复也被标记为不安全。因为在这种情况下，无法准确判断在对 __slots__ 进行排序时，该注释应随哪个项目移动。

class Bar:
    __slots__ = [
        "a", "c", "e",  # a comment
        "b", "d", "f",  # a second  comment
    ]

最后，只要 Ruff 检测到同一文件中的其他代码以某种方式读取了 __slots__ 变量，且该变量未被赋值给集合（set），本规则的修复就会被标记为不安全。这是因为如果类的 __slots__ 被迭代或被赋值给其他变量，其中项目的顺序可能具有语义含义。

在绝大多数其他情况下，本规则的修复不太可能导致破坏；因此，Ruff 在其他情况下会将此规则的修复标记为安全。但请注意，（尽管很少见）__slots__ 的值仍可能被 __slots__ 定义所在模块之外的代码读取，在这种情况下，本规则的修复在理论上可能会导致代码损坏。