Skip to content

Require explicit annotations for List[object] and Dict[*, object] #6792

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 5 commits into from
Closed

Require explicit annotations for List[object] and Dict[*, object] #6792

wants to merge 5 commits into from

Conversation

jxcl
Copy link
Contributor

@jxcl jxcl commented May 7, 2019 •
edited
Loading

This currently breaks mypy typechecking. Including instances like

def get_reachable_graph(root: object) -> Tuple[Dict[int, object],
                                               Dict[int, Tuple[int, object]]]:
    parents = {}
    seen = {id(root): root}

Should seen require explicit annotation, or presumably mypy should be smart enough to figure this out.

(#3816)

@jxcl jxcl force-pushed the 3816-no-inferred-object branch from 1923819 to b200ed8 Compare May 7, 2019 17:23
ilevkivskyi
ilevkivskyi reviewed May 7, 2019
View reviewed changes
Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

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

Thanks! The general logic looks good. I have some suggestions here

@jxcl jxcl force-pushed the 3816-no-inferred-object branch from 294bfb1 to afac318 Compare May 8, 2019 16:11
@ilevkivskyi
Copy link
Member

Please don't force-push and/or rebase, this makes reviewing much harder, just push more commits and merge when necessary.

@jxcl jxcl force-pushed the 3816-no-inferred-object branch from afac318 to 6cce5ad Compare May 8, 2019 16:18
@jxcl
Copy link
Contributor Author

jxcl commented May 8, 2019

Sorry, didn't see that until my last force push. I will stop.

jxcl
jxcl commented May 8, 2019
View reviewed changes
ilevkivskyi
ilevkivskyi reviewed May 8, 2019
View reviewed changes
Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

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

Thanks for updates! I have few more comments. Also you didn't implement interaction with --allow-untyped-globals which is important, since this generates some extra errors. There is also a lint error. Finally, self-check still fails, but now the errors look more reasonable.

jxcl
jxcl commented May 8, 2019
View reviewed changes
ilevkivskyi
ilevkivskyi reviewed May 9, 2019
View reviewed changes
Copy link
Member

@ilevkivskyi ilevkivskyi left a comment

Choose a reason for hiding this comment

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

Thanks for updates! The logic LGTM now, I only have few minor style comments.

Also after reading again, I think it makes sense to add dedicated tests (apart from fixing existing tests). Mostly to test that this is not triggered where it shouldn't, for example:

class C:
    def __init__(self) -> None:
        self.x = [object()]

c: C
c.x = [1, '2']  # this should be OK

Also I encourage you to add the necessary fixes in mypy code to fix self-check to this PR. This is the best way for us to double-check whether current heuristic is "smart enough".

@jxcl
Copy link
Contributor Author

jxcl commented May 9, 2019

Re: Guido's comment on the issue, should I add another option to disable this behavior to preserve some backwards compatibility?

@JukkaL
Copy link
Collaborator

JukkaL commented May 9, 2019

It may be best to first only enable this through a flag, and once we've successfully used this with a few big codebases (for example, with internal Dropbox codebases) in addition to mypy we can make this enabled by default (or always).

@ilevkivskyi
Copy link
Member

It may be best to first only enable this through a flag, and once we've successfully used this with a few big codebases (for example, with internal Dropbox codebases) in addition to mypy we can make this enabled by default (or always).

Why can't we just try it with Dropbox code bases now, even before merging? Adding new flag is still some effort, so I would propose to first address existing comments, add tests, make CI build green (this may already highlight some problems in mypy self-check, as I mentioned in my review), and then I will try this PR against our internal code bases to see how well it works.

@jxcl
Copy link
Contributor Author

jxcl commented May 20, 2019

Other test fixes still incoming

@ilevkivskyi
Copy link
Member

What is the status here? This has a merge conflict and some tests still fail.

msullivan
msullivan requested changes Feb 21, 2020
View reviewed changes
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.

Needs to be fixed

@ChetanKhanna ChetanKhanna mentioned this pull request Jun 12, 2020
Open
@ChetanKhanna ChetanKhanna mentioned this pull request Jun 26, 2020
Closed
@msullivan
Copy link
Collaborator

Closing this in favor of #9051. (Which I'm not sure if it will get merged, but.)

@msullivan msullivan closed this Oct 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ilevkivskyi ilevkivskyi ilevkivskyi left review comments

@msullivan msullivan msullivan requested changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@jxcl @ilevkivskyi @JukkaL @msullivan