Skip to content

Improve handling of future annotations.#53

Merged
dnwpark merged 3 commits intomainfrom
future-anotations
Jan 26, 2026
Merged

Improve handling of future annotations.#53
dnwpark merged 3 commits intomainfrom
future-anotations

Conversation

@dnwpark
Copy link
Copy Markdown
Contributor

@dnwpark dnwpark commented Jan 24, 2026

Adding from __future__ import annotations breaks a lot of stuff. This is a best attempt at dealing with string annotations.

  • Evaluate string annotations in get_local_defns
  • Evaluate string annotations when evaluating types.
  • Annotations may produce unions T | None in place when resolved....
  • A best effort at getting namespaces for type and function type hints.

@vercel
Copy link
Copy Markdown

vercel bot commented Jan 24, 2026

@dnwpark must be a member of the Vercel Labs team on Vercel to deploy.
- Click here to add @dnwpark to the team.
- If you initiated this build, request access.

Learn more about collaboration on Vercel and other options here.

@dnwpark dnwpark requested a review from msullivan January 24, 2026 02:52
Base automatically changed from move-tests to main January 26, 2026 19:14
else:
annos[k] = v
elif af := getattr(boxed.cls, "__annotations__", None):
# TODO: substitute vars in this case
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may wish to keep this TODO for the non str case?

# Replace string annotations with resolved types
globalns, localns = _get_class_type_hint_namespaces(obj)
hints = {
k: _eval_types(v, ctx)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to _eval_types here?

And more generally I suppose, is this where we want to do this?
Maybe we'd want to do it in the helpers for Members?
I'm not sure

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need something like this to resolve a case like this:

class A:
    b: B
    
class B:
    c: C
    
class C:
    pass
    
t = eval_typing(A)
assert t.__annotations__['b'].__annotations__['c'] is C

If we don't recursively eval, the inner annotations will stay as strings.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that bothers me

@vercel
Copy link
Copy Markdown

vercel bot commented Jan 26, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Review Updated (UTC)
python-typemap Ready Ready Preview, Comment Jan 26, 2026 9:15pm

@dnwpark dnwpark marked this pull request as ready for review January 26, 2026 21:14

@_eval_types_impl.register
def _eval_type_type(obj: type, ctx: EvalContext):
# Ensure that any string annotations are resolved
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling _eval_type_type on a child class that inherits annotations (without defining its own) corrupts the parent class's __annotations__ dict.

Fix on Vercel

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnwpark check if the robot is right about this?

@dnwpark dnwpark merged commit 7941244 into main Jan 26, 2026
5 checks passed
@dnwpark dnwpark deleted the future-anotations branch January 26, 2026 21:59
@msullivan
Copy link
Copy Markdown
Collaborator

Though also I think I stand by that we maybe shouldn't be doing those evaluations anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants