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

Ability to see errors in editor #26

Open
chadrik opened this issue Apr 25, 2019 · 6 comments
Open

Ability to see errors in editor #26

chadrik opened this issue Apr 25, 2019 · 6 comments
Labels
enhancement New feature or request help wanted Extra attention is needed priority-high

Comments

@chadrik
Copy link

chadrik commented Apr 25, 2019

I had a quick play with this plugin and it's an improvement over using a shell, but it's not very tightly integrated into the editor. It would be great to see a bit of the approach used by https://github.com/leinardi/mypy-pycharm integrated here. That plugin looks like it is not actively maintained any longer, and just getting it to detect the mypy executable is a huge PITA (for some reason it's trying to use my system's python2 interpreter), but the big thing it has going for it is the ability to see errors in the editor, which is pretty slick. It gives you a bi-directional relationship between editor view and error view, whereas with this plugin it seems I have only a uni-directional relationship from error-to-editor.

@ilevkivskyi ilevkivskyi added the enhancement New feature or request label Apr 25, 2019
@ilevkivskyi
Copy link
Contributor

I actually thought about this. But this may be misleading, because the code is not re-checked immediately when you edit it. So it will be underlined as an error even after you fix the error.

In other words, this issue and #19 should go together. Btw, now that we have 300-500ms mypy daemon response time (even for huge code bases), this looks like a reasonable feature to have.

@chadrik
Copy link
Author

chadrik commented Apr 25, 2019

Hi Ivan!

Btw, now that we have 300-500ms mypy daemon response time (even for huge code bases), this looks like a reasonable feature to have.

I'm finally on the verge of deploying mypy on our existing (moderately large) code base, but I've been struggling to get dmypy rerun times to a level where I feel comfortable running it automatically (e.g. prior to commit, or within a PyCharm plugin). With the mypyc update, regular mypy run times went from 1:30 to 30s (amazing!). With dmypy it's taking about 15s to rerun if I edit any files, and <1s if nothing has been edited. That's adequate but it's certainly not the 300-500ms that you're getting. I'm using 0.701. Do I need to be using the latest from master branch? Or are there some key techniques I should be using?

Thanks again for all your amazing contributions to this ecosystem.

@ilevkivskyi
Copy link
Contributor

No, these are times for 0.701. Internally we are using a script that is basically a wrapper around dmypy recheck [--update|--remove]. We received a report from another user a while ago also reporting super slow daemon runs (10-20s for a moderately large codebase).

TBH this is a mystery that I would like to be solved, but I can't reproduce this. Maybe you could start the daemon with -vv and check for any anomalies in the daemon log file?

@chadrik
Copy link
Author

chadrik commented Apr 25, 2019

Ok, I created an issue over at mypy.

@syastrov
Copy link

This would be an extremely useful feature. FWIW dmypy takes about 100ms to check 20k lines of code, so this would be perfectly acceptable for my use case. I have a wrapper script which uses git ls-files to find which files to check (so I can exclude things) and that takes 60ms itself, so in total, it takes 160ms.

@ilevkivskyi
Copy link
Contributor

Yeah, this would make most sense together with #19.

@ilevkivskyi ilevkivskyi added priority-high help wanted Extra attention is needed labels Nov 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed priority-high
Projects
None yet
Development

No branches or pull requests

3 participants