Use imports to collect (scoped) type information #63
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.
Jan
orDay
will be picked up as implicitly available symbols in the given module.dogs
will 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.January
will 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