Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Move pythoneval to use mypy.api.run #4025

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
wants to merge 1 commit into from

Conversation

emmatyping
Copy link
Member

This replaces the old subprocess based method. In addition, the test cases
are no longer run, in order to reduce test time. This has led to a 10-20%
speedup in pytest. This might help with #3895, as it removes the
subprocesses.

Fixes #1671

Two follow up ideas:

  • Move testcmdline to use mypy.api.run as well
  • Add support for StringIO inputs to mypy and use it so we don't have to write out to files all the time.

This replaces the old subprocess based method. In addition, the test cases
are no longer run, in order to reduce test time. This has led to a 10-20%
speedup in pytest. This might help with python#3895, as it removes the
subprocesses.

Fixes python#1671
@elazarg
Copy link
Contributor

elazarg commented Sep 28, 2017

This PR looks like a good idea regardless of performance and flakes, since it makes the test more cohesive.

StringIO sounds very good! In addition to potential speedup of test execution, it will also speed up test discovery but an order of magnitude (I intended to do that by deferring the act of writing the files). I'm interested to know what are the potential downsides; I can't see any.

Regarding testcmdline, I don't think it's a good idea not to test the interface between the OS and the program. Instead it might be possible to split the tests - test that passed flags correspond to the internal flags (using subprocess), and test that internal flags have the desired effect (using API).
But maybe I'm overcomplicating things.

@elazarg
Copy link
Contributor

elazarg commented Sep 28, 2017

Do the tests re-analyze typeshed each time?

@emmatyping
Copy link
Member Author

I don't think it's a good idea not to test the interface between the OS and the program

That is why I decided to not include that in this PR. I do like the idea of splitting them up.

StringIO would require a bit of work on the mypy internals, but I think it is worth it.

As for typeshed, yes, I believe they do re-analyze each run, but an optimization there would likely be complicated.

@elazarg
Copy link
Contributor

elazarg commented Sep 28, 2017

But incremental mode might help? (I think caching mypy's state after analysis might be very useful, but that's slightly OT)

@emmatyping
Copy link
Member Author

Incremental may help, if you want to continue this discussion the best place is probably #1668.

@emmatyping
Copy link
Member Author

This change has the additional benefit of making us completely independent of a runtime Python 2 interpreter, fixing #4039.

@gvanrossum
Copy link
Member

In addition, the test cases are no longer run, in order to reduce test time.

While I appreciate the speedup, I worry that over time these test cases might stop working when executed. There are still quite a few places where mypy passes code that doesn't actually work at runtime. Every time a test case in this category is added or changed we would risk that we'd be testing something imaginary. This is particularly worrisome for tests that are trying to ascertain that mypy matches subtle runtime behavior.

@emmatyping
Copy link
Member Author

Okay, that makes sense. I believe several of the tests can be removed anyway (they test extremely basic things), so that will cause some speed increases.

@gvanrossum
Copy link
Member

gvanrossum commented Oct 2, 2017 via email

@emmatyping
Copy link
Member Author

I will open a new one, I think it will be cleaner.

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.

3 participants