Add support for attrs.fields

[Tinche]

Howdy Mypy friends.

This add support for attrs.fields, which is a nicer way of accessing the attrs magic attribute.

[Tinche]

Great feedback. Looks like I'll need to switch to get_function_signature_hook instead of get_function_hook though. get_function_hook appears to run after type-checking, so the attrs stubs for fields are interfering with the TypeVar handling.

[ikonst]

I'll try to take a look tomorrow.

[Tinche]

@hauntsaninja Hello, I know you mentioned the plugin subsystem isn't really your thing, but could you recommend someone else to help review this? <3

[JelleZijlstra]

I can review this, please fix the merge conflict first though.

[Tinche]

@JelleZijlstra Thank you! Done.

[Tinche]

I don't think this PR will handle unions properly, but I consider this an advanced use case and can tackle it in a future PR.

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

graphql-core (https://github.com/graphql-python/graphql-core) got 1.05x slower (282.3s -> 297.1s)

[jhance]

I don't believe that inferring a fixed-length tuple here is actually that useful. In actual uses of attr.fields in our codebase, we tend to iterate over the attr.fields, but when you do that, the value is computed as object rather than attr.Attribute. e.g.

for field in attr.fields(Foo):
    reveal_type(field)

now reveals builtins.object when I want something more like attr.Attribute[Any].

[Tinche]

I'm pretty bullish on this change since it unlocks very interesting stuff, both by itself and down the line, such as python-attrs/attrs#1144.

That said, maybe we can stick a custom __iter__ on the result type to fix this issue in particular?

[JukkaL]

That said, maybe we can stick a custom iter on the result type to fix this issue in particular?

Yeah, I think this could work. @jhance What do you think?

[jhance]

I am more interested in basic cases continuing to work than supporting more interesting advanced cases. I am not sure how you would add an extra __iter__ to the TupleType return value here.

I'm happy to have this feature if it doesn't break basic use cases, but resolving the breakage here is blocking release for us. I am going to include the revert in the release branch for 1.4.0, but wait on reverting in master until we have a plan for what we want to do here.