Parse mypy type comments

jendrikseipp / vulture

Find dead Python code

MIT License

3.48k stars 152 forks source link

Parse mypy type comments #220

Closed jingw closed 4 years ago

jingw commented 4 years ago

Description

This prevents type-only imports from being flagged as unused.

Implementation decision note: As typed_ast will not be updated to support parsing Python 3.8+ syntax, I'm choosing not to use it. The downside of using Python's built-in type comment support is that it requires Python 3.8+. Someone more motivated than me could potentially make vulture use both, but I don't feel it's worth the complexity/effort given typed_ast seems likely to eventually die.

Related Issue

Fixes #152 See also #153

Checklist:

[x] My code follows the code style of this project.
[x] I have updated the documentation in the README.md file. (but do you want this in the README? not sure how much you want there versus left to --help)
[x] I have added an entry in CHANGELOG.md.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

jingw commented 4 years ago

Now that I look around, I see flake8 complains about bad type comments by default, without any obvious option to disable that. I'll go ahead and make the proposed change.

Originally, I decided to mirror the logic in https://bugs.python.org/issue35766 (the PR that added type_comments to ast.parse)

By default, ast.parse() should not return type comments, since this would reject some perfectly good Python code (with sonething looking like a type comment in a place where the grammar doesn’t allow it). But passing an new flag will cause the tokenizer to process type comments and the returned tree will contain them.

That said, I imagine vulture does not need to be as careful as the standard library with regards to backwards compatibility.

jingw commented 4 years ago

Done! I've made it automatically gate on Python 3.8+

jendrikseipp commented 4 years ago

Thanks a lot for your work on this!

djh82 commented 3 years ago

Apologies for being the PR necromancer; what was the rationale behind only enabling this for py3.8+? Especially given 3.6+ supports typing (and was introduced in the now EOL 3.5)? I didnt want to raise a new issue, if there was a good reason for it. Thanks!

jendrikseipp commented 3 years ago

Please see the issue description for the reasoning. In short: we don't think that the extra work is worth it.