Skip to content

Fully analyze named tuple subclasses in third pass #5644

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

Merged
merged 5 commits into from
Sep 19, 2018

Conversation

ilevkivskyi
Copy link
Member

Fixes #5195

The fix is straightforward, previously tuple_type was not analyzed for named tuple subclasses.
I also copy the line number for instance types when transforming them.

Copy link
Collaborator

@msullivan msullivan left a comment

Choose a reason for hiding this comment

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

Looks good.

Is there a similar transformation that ought to be done for typeddict_type as well?

@ilevkivskyi
Copy link
Member Author

Is there a similar transformation that ought to be done for typeddict_type as well?

I think no. A subclass of a typed dict is also a typed dict (i.e. it becomes itself a "magic" class), while subclassing a named tuple creates a more "normal" class. But I think it makes sense to add a test just for completeness.

@ilevkivskyi ilevkivskyi merged commit 28b1bfe into python:master Sep 19, 2018
@ilevkivskyi ilevkivskyi deleted the rec-tuple-crash branch September 19, 2018 23:37
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.

Recursive subclass of NamedTuple crashes mypy
2 participants