-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Document how plugins can support the new semantic analyzer #7135
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the docs! Looks good, I have some suggestions.
mypy/plugin.py
Outdated
The new semantic analyzer (enabled through the --new-semantic-analyzer flag) | ||
changes how plugins are expected to work in several notable ways: | ||
|
||
1. The order of processing modules is different. The old semantic analyzer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe say "order of processing statements in modules"? Otherwise people may get confused that just the order of modules in SCC is different and will not read further.
mypy/plugin.py
Outdated
1. The order of processing modules is different. The old semantic analyzer | ||
processed modules in textual order, one module at a time. The new semantic | ||
analyzer first processes the module top levels, including bodies of any | ||
top-level classes. Functions and methods are processed only after module |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarify here that "top-level" means not nested in functions/methods. Classes nested in other classes are still processed.
mypy/plugin.py
Outdated
This also means that function signatures in the same module have not been | ||
analyzed yet when analyzing the module top level. If you need access to | ||
a function signature, you'll need to explicitly analyze the signature first | ||
using `type_anal()`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is anal_type()
, not type_anal()
.
mypy/plugin.py
Outdated
to call this if `anal_type` returns None, however. | ||
|
||
5. There is a new API property `final_iteration`, which is true once the | ||
maximum semantic analysis iteration count has been reached. You must never |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe mention this can be also True
sooner if mypy detected no progress during last iteration?
analyzed. | ||
|
||
You can use `api.options.new_semantic_analyzer` to check whether the new | ||
semantic analyzer is enabled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this added info be also added to docs/source/extending_mypy.rst
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! I have no further comments.
Work towards #7071 (and more).