Draft: Add "resolve_types" argument to define()

[sscherfke]

Fixes: #1286

Summary

Add resolve_types kwarg to define() to allow it to automatically resolve the class' fields types.

This is atm just a PoC to evaluate if this is going into the right direction. What do you think, @hynek ?

Pull Request Check List

• Do not open pull requests from your main branch – use a separate branch!
  • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
  • This is not a pre-requisite for your pull request to be accepted, but you have been warned.
• Added tests for changed code.
  Our CI fails if coverage is not 100%.
• New features have been added to our Hypothesis testing strategy.
• Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
  • ...and used in the stub test file tests/typing_example.py.
  • If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
• Updated documentation for changed code.
  • New functions/classes have to be added to docs/api.rst by hand.
  • Changes to the signatures of @attr.s() and @attrs.define() have to be added by hand too.
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
    The next version is the second number in the current release + 1.
    The first number represents the current year.
    So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
    If the next version is the first in the new year, it'll be 23.1.0.
    • If something changed that affects both attrs.define() and attr.s(), you have to add version directives to both.
• Documentation in .rst and .md files is written using semantic newlines.
• Changes (and possible deprecations) have news fragments in changelog.d.
• Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

[hynek]

typing is @Tinche territory ;)

[Tinche]

What's the exact use case here?

A couple of notes:

• On 3.14 we likely won't need resolve_types any more
• If resolve_types can be called immediately (no forward refs), the consumer of the annotations can call it if they see a string annotation - the producer shouldn't need to worry about it

[sscherfke]

This is purely for convenience. I also implemented this in the Typed Settings' settings decorator (MR, fixup).

So I don't really require it for TS but I was wondering if this might improve convenience for other users / use cases as well.

Why won't this be needed on py314 anymore? I thould that annotations would allways be "unresolved strings" in a future Python version and that thus, resolve_types() would be even more important?

[sscherfke]

@Tinche ping :)

[Tinche]

Here's my understanding of how PEP 649 works in 3.14.

Attrs itself will need to use get_annotations with format=STRING. attrs is only concerned with whether an annotation is a ClassVar, if memory serves.

All other code that runs after the class and all other classes it references are defined (cattrs) will use format=VALUE and let the interpreter resolve the types. The way we expose this would probably be by making Attribute.type a property or something that calls get_annotations under the hood.

Even ignoring all of that, I don't think resolve_types on define makes too much sense - it would make more sense on fields. Folks generally use stringified annotations when they have forward references, and those cannot be resolved when the class is constructed, but sometime later.