Skip to content

-s disables cross-checks between listed files #2012

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

Closed
toejough opened this issue Aug 11, 2016 · 4 comments
Closed

-s disables cross-checks between listed files #2012

toejough opened this issue Aug 11, 2016 · 4 comments

Comments

@toejough
Copy link

toejough commented Aug 11, 2016

I'm having a compound issue, and I'm not sure if each part of this deserves an issue. The thing that bothers me the most is the missing cross-checks, but to get there, it might be helpful to explain some context...

I've got a project that:

  • uses local, fully typed files
  • uses a third-party, fully typed module (call it is_typed)
  • uses a third-party, untyped module (call it not_typed)

If I run mypy a.py b.py initially, I get an error about how it can't find is_typed, and maybe I should either use MYPYPATH or --silent-imports.

When I run MYPYPATH="/path/to/virtualenv/site-packages" mypy a.py b.py, I get a ton of failures related to not_typed, plus a few about failures where a.py calls something in b.py with the wrong type.

These last set are the errors I'm calling cross-check failures. I want to see those. I don't want to see the earlier set - I know that not_typed is not typed, and I'm not going to make stubs for that project at the moment.

Back to the example. Setting the full site-packages dir grabbed more than I wanted. If I run MYPYPATH="/path/to/virtualenv/site-packages/is_typed" mypy a.py b.py, I get AssertionError: Neither id, path nor source given, with a stack trace. If I add --pdb to the call to try to debug, I do not get dropped into the debugger.

Ok. Well, let's try the --silent-imports then. mypy -s a.py b.py results in a clean run. The cross-check failures do not show up, even though they're still there. :-(

Ok. Well, let's try from not_typed.sub import thing # type: ignore . Then run MYPYPATH="/path/to/virtualenv/site-packages" mypy a.py b.py again aaaaand... All the errors for not_typed.

So then I got desperate and tried thing = importlib.import_module('not_typed.sub').thing, and that resulted in Invalid Type "b.thing" everywhere I used the thing type in b.py.

I think I ran into several real problems here, but I'm not convinced I'm not just doing it wrong somehow, because I don't see anyone else having the same issues here, and I don't think my use case is all that tricky.

Is there anything I can do differently?

@gnprice
Copy link
Collaborator

gnprice commented Aug 12, 2016

Thanks for this writeup! I think the shortest direct answer is that we don't currently have great support for third-party libraries that have themselves adopted PEP 484 types -- that is, for libraries that aren't in your own codebase's source tree and live instead in something like a site-packages/, but that have their own inline annotations which you'd like to use rather than finding or writing stubs.

Clearly this is a situation that will become more and more important as more library authors adopt static type annotations -- we should definitely find a better solution than we have.

The workflow that currently definitely does work great is: all the files you want to actually type-check are in your source tree, and you pass them (or the directories containing them) to a mypy command line. All the external libraries you use either have stubs, or they don't have type annotations, and if any are in the latter situation then you pass --silent-imports on your mypy command line.

That workflow is pretty much what you describe with mypy -s a.py b.py, and it should work great -- unless the errors you want to see are dependent on having the actual types from is_typed, in which case you would need stubs for is_typed in order to use that workflow. Is that your situation? If not, there may be a different issue present.

Issue #1190 is the main one we have discussing this problem. Does that look like it covers what you're describing?

@gvanrossum
Copy link
Member

gvanrossum commented Aug 12, 2016 via email

@toejough
Copy link
Author

@gvanrossum - ah, ok. thanks for the tip!

@gnprice - thanks for the response!

So, maybe I should stop filing bugs at the end of my work day. #1190 is definitely part of the problem I was having, so thanks for pointing that one out.

The bigger part of my problem, though, was that it seemed like -s was hiding errors where a.py called a b.py function with the wrong types. I've made a bunch of changes to my actual code since then (and unfortunately squashed them all down, so I can't get back to where I was when I filed the issue), and now I can't reproduce that condition. I can't reproduce it with a minimal example, either, so I guess I'll close this issue.

My best guess is that the type error I was looking for was actually dependent on is_typed's types, which means that yes, my whole problem is covered by #1190.

Thanks again for the responses and thought - and apologies for the noise. If I can reproduce AND get it down to a minimal example, I'll open a new issue, but for now I'd consider this one closed.

@gvanrossum
Copy link
Member

gvanrossum commented Aug 12, 2016 via email

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

No branches or pull requests

3 participants