Ruff, ty, and __slots__ checks

[ariebovenberg]

Ruff’s foray into type checking opens opens up some interesting possibilities regarding __slots__. Would you be open to adding more checks?

__slots__ are an optimization to reduce memory overhead of objects. The problem with __slots__ is that it’s really hard to keep them correct. And there’s no mechanism in the language to alert you of common mistakes like:

1. Defining slots, but not using some of them
2. Defining duplicate slots
3. Defining slots that overlap with a superclass
4. Defining slots while inheriting from a non-slots class, which renders the slots essentially useless

Ruff already checks for (3) (PLW0244). I myself created slotscheck that is able to detect (2) and (4) as well. But unfortunately, it needs to be a “runtime” check in order to infer the inheritance tree. Using ruff/ty’s advanced static analysis, it might be possible to detect all four types of issues statically.

Do you think it’d be feasible to include in ruff or ty? I’d be happy to dig into this if you’re open to the idea.

Thinking further, it might even be possible to automatically define slots—taking it completely out of the developers’ care while giving them free memory savings and guarding against invalid attributes at runtime.

[MichaReiser]

Absolutely, our goal is that our new semantic model will be able to power rules like this that require cross-file analysis (and understanding type hierarchies etc).

However, we're not quiet there yet. Ruff doesn't use the new analysis engine and our focus for ty is on shipping a type checker first. It's also a somewhat open question whether we'll start using ty's semantic model in Ruff or if we'll start adding lint rules to ty. But we're definitely invested in enabling more powerful lint rules long term.