pyright support via dataclass transforms

[asford]

pyright is adding support for attrs classes in static type checking through a source-level extension mechanism called dataclass transforms. This will provide support the strict-subset of attrs class semantics implemented as standard-library dataclasses in pyright, and by extension pylance and VS Code.

Relevant project issues include:

microsoft/pyright#1782 - Discussion thread for feature
microsoft/pylance-release#226 - pylance tracking issue.
microsoft/pyright#146 - pyright ur-issue.
microsoft/pyright#1773 - Initial PR
https://github.com/microsoft/pyright/blob/master/specs/dataclass_transforms.md - Current spec in master

Would y'all be open to a PR implemented the recommendations in the linked specification?
Perhaps there's a dialog to be had to ensure that the upcoming next-gen decorator semantics can be supported via this extension mechanism? (I don't have enough of the picture in mind to understand whether this is true.)

edit - Updating cross-refs I'd originally missed and rephrasing description. This connection had already been made!

[hynek]

Yes, Eric was kind enough to reach out to me a few weeks ago and we discussed the topic.

Their integration doesn't cover all of our features but it seems good enough – at least good enough to not deliver false positives. NG APIs should work too.

I was hoping for feedback from @euresti (or any other typing gurus around here, really) before going to town on it. But maybe we can indeed squeeze it into 21.1 – at least provisionally.

[hynek]

Also pulling in @Tinche who seems to have already played with it!

[Tinche]

Seems to work for me. The cost/benefit analysis seems in favor of adding this: it's very easy for us to do and IDE support is very useful, particularly if you're not quite ready to start using mypy.

[asford]

I've also verified this on an internal codebase and found it to be generally functional.

Pleasantly, this allows us to implement attrs excellent advice on wrapping the decorator in a reasonably straightforward fashion, however as you mention is is a subset of both attrs' current semantics and the mypy-attrs plugin's current semantics.

I do feel that there's some value in having attrs begin to support this provisionally. It's a huge potential boost to VS Code users and could be a good way to drive more feedback on the pyright spec on additional "non dataclass" semantics like converter.

[euresti]

This is interesting. Similar to an idea I had for supporting this in python/mypy#5406 (comment)

I wonder if this could be used in mypy itself. Might be complicated with all the caching mypy does, but ... maybe?

[euresti]

How does it work with the overloads? Do you only annotate the real implementation? Can these be put in a .pyi file?

[hynek]

@euresti did you get Eric’s e-mail? He sent it to your GitHub address. That would be the best way to get direct answers. :)

[asford]

How does it work with the overloads? Do you only annotate the real implementation? Can these be put in a .pyi file?

Quick link to a gist-playground as well for interested parties:

https://gist.github.com/asford/cd3c8ebbf245df6c3666eec0852c171d

[hynek]

If someone wants to give it a shot, it would be great to squeeze this into the overdue 21.1 release that will come out next week come hell or high water. Seems like enough of y'all have played with it so I'd be delighted if y'all could cooperate on getting it done. :)

[asford]

I threw a very minimal PR together at #796 IFF you would like to fast-track support for this provisionally in 21.1.

[erictraut]

@jakebailey just pointed out something that I had missed previously. It appears that attr.ib and attr.field use the parameter name factory. Dataclasses (and the dataclass_transform spec) use the name default_factory. That mismatch means that the following example (which is used in the attrs documentation) generates errors in pyright:

from typing import List
import attr

@attr.s(auto_attribs=True)
class SomeClass:
    a_number: int = 42
    list_of_numbers: List[int] = attr.field(factory=list)

I can think of two solutions here:

1. attr.field could be amended to accept default_factory rather than (or in addition to) factory
2. The dataclass_transform spec could accept both default_factory and factory

I don't like option 2 because it would be an attrs-specific accommodation to the spec. What do you think about option 1? Can you think of any other options I'm missing?

[hynek]

factory=list is syntactic sugar for default=Factory(list) that has been added after much complaining over the years. Making it long again would almost completely obliterate the point of its very existence.

So in this case it would be really nice if we could go with option 2 (if making it configurable is out of the question). I know that my code bases are full of the "sweet" alternative and I'd hate to change it to the long one.