Use imports to collect (scoped) type information#63
Merged
Conversation
3a3315a to
033d560
Compare
"from imports" are collected as types within the scope of the containing module. E.g. "from pathlib import Path" will allow using "Path" inside the modules scope. "import" without "from" are collected as scoped type prefixes. Meaning if a module contains "import scipy as sp", "sp." can be used as a valid type prefix in that module.
And also improve the class representation and various other things.
`py_import` can already be imported manually in the module's namespace. In which case `py_import` cannot be formatted as an import and shouldn't be collected.
033d560 to
945b59e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #20.
Adds support for collecting additional type information from existing imports in the parsed package. Also does quite a bit of internal refactoring and maintenance.
E.g. with this
will work out of the box.
JanorDaywill be picked up as implicitly available symbols in the given module.dogswill be collected as an import prefix in the module. They won't be available in other modules that don't feature these import statements.We could also make these available to be used in other modules but for now I think this more conservative approach should be a good trade-off. It should save users from having to specify a large number of types manually. And weird import choices or naming conflicts are guarded by the scoping.
However,
calendar.Januarywill be collected as a global type and can be used in other modules.This makes it more apparent that a full reference on docstubs type inference would be good to have in the documentation.
Release note