Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wip] Basic PoC of Expand type for TypedDict-kwargs #7051

Closed
wants to merge 2 commits into from

Conversation

untitaker
Copy link

@untitaker untitaker commented Jun 24, 2019

This implements Expand in kwarg positions as per #4441. TODO:

  • Forbid usage of Expand outside of *args and **kwargs (what does x: Expand[...] = 42 even mean?)
  • Implement Expand properly s.t one can import it at runtime
  • Commit the changes to mypy_extensions
  • tests

Right now this PR only exists as a discussion basis for the approach I should take when implementing this properly. Adding expand_formal_type seems to be the best way to me right now but I don't have good oversight over the entire codebase to know any better.

@untitaker untitaker changed the title Basic PoC of Expand type for TypedDict-kwargs [wip] Basic PoC of Expand type for TypedDict-kwargs Jun 24, 2019


def expand_formal_type(formal_type: Type, actual_name: Optional[str], tuple_idx: int) -> Type:
if isinstance(formal_type, Instance) and formal_type.type.fullname() == 'mypy_extensions.Expand':
Copy link
Author

Choose a reason for hiding this comment

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

This is ugly. How do I get something like TypedDictType (ExpandType) and make mypy map mypy_extensions.Expand to mypy.types.ExpandType?

@ilevkivskyi
Copy link
Member

Thanks for PR!

I think it should be done in a different way: it will be simpler if most of things happen during semantic analysis rather than type checking. Note that we currently have two semantic analyzers (things that construct symbol tables and bind reference expressions to symbols). The old one will be deprecated soon, so I propose to only support this with the new one (located in mypy/newsemanal). Here are some comments:

  • Expand should be prohibited everywhere except in **kwargs.
  • This should not be a proper type but rather a name qualifier (like Final or ClassVar)
  • Type analyzer should modify function in place during semantic analysis using the expanded version (see mypy.newsemanal.typeanal.TypeAnalyzer.visit_callable_type)
  • At the same time, the analyzer should insert a kwargs variable (having the actual explicit TypedDict type) in the local symbol table, see around here.

Let me know if you have more questions.

@untitaker
Copy link
Author

I think I don't have the motivation to work on this anymore, sorry.

@untitaker untitaker closed this Jul 11, 2019
@untitaker untitaker deleted the feat/expand-types branch July 11, 2019 13:28
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.

None yet

2 participants