Use of AttrsInstance protocol is incompatible with type checkers other than mypy

[layday]

The latest release introduced the AttrsInstance protocol with one attribute, __attrs_attrs__, which replaced Any in the signature of various core functions. The __attrs_attrs__ attribute is "injected" by the attrs mypy plug-in; other type checkers have no knowledge of this attribute and adding attributes to the type definition of a dataclass-like class is not supported by dataclass_transform. Therefore, functions such as fields and asdict generate type errors by default in all type checkers other than mypy. I am not familiar with mypy plug-ins but I assume one alternative would be to remove the attribute from the protocol definition and inject it dynamically from the plug-in, the way it's done for the attrs class. Longer term, an extension to dataclass_transform could be sought.

[Tinche]

Pyright has no plugin interface, so there's not much we can do. Maybe you can open an issue over there?

[layday]

It's a topic that's been discussed repeatedly - Pyright is opposed to adding support for plug-ins. Their resistance to plug-ins is dataclass_transform's raison d'etre.

[hynek]

I'm really not sure what to do about all of this. pyright has become a bottle-neck in typing and compared to it, nobody uses mypy. We feel that at all ends.

[layday]

I'm not sure I agree.

Pyright has a large audience but the majority of it I would say is Pylance code completion users - Python beginners, hobbyists, data scientists and the like - or even software devs who only use it for completion in their editor. OTOH, mypy is a mainstay of Python software developers and you won't see Pyright being used to type check any of the popular (and slightly less popular) libraries here on GH, either in CI or in devel.¹ I don't know what the situation's like in corporate - things might swing slightly in Pyright's favour - but I don't think mypy's anywhere near the point where no one's using it.

Pyright has been quick to adopt new standards and was (to my knowledge) the only type checker to implement the now rejected short form callable definition PEP. Its main author has also been involved in writing new typing PEPs and has been a very positive influence in the typing community, from what I've seen. I think bottleneck is a slightly unfair characterisation.

I don't think framing this in terms of Pyright vs Mypy is particularly insightful either; there are other type checkers out there, either without plug-in support or without a plug-in for attrs.

Footnotes

1. I think, primarily, because it's written in JS. ↩

[layday]

I asked on the Pyright tracker for their input, see microsoft/pyright#3808.

[hynek]

Pyright has a large audience but the majority of it I would say is Pylance code completion users - Python beginners, hobbyists, data scientists and the like - or even software devs who only use it for completion in their editor.

Yes, I don't think a substantive amount of people use pyright on its own, but VS Code is by far the most popular editor now (check out those install numbers https://marketplace.visualstudio.com/items?itemName=ms-python.python) and attrs features that get labeled in there as errors but pass CI...well you know. In the end it leads to the lowest common denominator of features being used.

As for other type checkers: they didn't matter too much by and large, because they never had close to MyPy's user base (Although pytype did ship attrs support out of the box, because Google uses attrs). Microsoft's firepower and influence comes 100% from VS Code.

[Tinche]

I agree with @layday in that in my experience pyright rules editor support/autocompletion, but mypy rules the linting space.

I disagree about pyright not being a bottleneck. For better or worse, nowadays if you want to move the typing space forward you need pyright support, and since pyright has no plugins that means going through the process of getting together a typing PEP and having it accepted. I've been going to these meetings, and I can tell you right now the community there is very particular about what they accept.

Even if pyright HAD plugins, the burden of having to write both a mypy and pyright plugin would be extreme.

I think our best bet is we focus on mypy and if our experiments work out and become popular, pyright will kinda have no choice but to implement them. In the meantime, we just deal with the fact editor support won't be there. It's not the end of the world.

What the ultimate solution is, I don't know.

[layday]

I might have a solution (for this particular issue) in #999.