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
pkg_resources
: Expose the type of imports and re-exports
#4242
base: main
Are you sure you want to change the base?
pkg_resources
: Expose the type of imports and re-exports
#4242
Conversation
pkg_resources/__init__.py
Outdated
import packaging.specifiers | ||
import packaging.requirements | ||
import packaging.markers | ||
import packaging.utils |
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.
This is a bit tricky...
Based on the comments:
- Fix all mypy issues #3979 (comment)
- Fix all mypy issues #3979 (comment)
- Fix all mypy issues #3979 (comment)
I suppose this would be a controversial change (I am not sure if it matters to have the if TYPE_CHECKING
in pkg_resources/__init__.py
or pkg_resouces/extern/__init__.py
, probably the comments apply to both).
At the end of the day, mypy
cannot handle MetaPathFinder
s... I suppose that the ultimate solution would be to use a mypy plugin to "convince" mypy
to use the files in the */_vendor
folder for the *.extern
modules, but that sounds very complicated1. So there is a trade-off here: complexity of implementing a mypy
plugin vs. in the duplication in *.extern
modules vs. leave the things unchecked (and loosing some of the benefits of the type analysis).
@jaraco, do you have any opinion about this one?
Footnotes
-
I cannot find a hook for finding modules in the docs: https://mypy.readthedocs.io/en/stable/extending_mypy.html#extending-mypy-using-plugins. So I opened https://github.com/python/mypy/issues/16988 for guidance on this. ↩
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's slightly different from what I originally did in #3979 in that it's only duplicating what's needed/used. And doing so right next to the equivalent dynamic imports. So imo there's less of a maintenance concern.
packaging.requirements
is especially important to avoid looking like we're subclassing Any
for RequirementParseError
and Requirement
W/o the import behind a TYPE_CHECKING
:
FWIW, I'd rather loose on type safety internally, publicly loose on implicit return types (until all public API return types are explicit), and loose on some super class typing, than going for a mypy plugin. Which also only works on mypy, not pyright, VSCode+Pylance, or PyCharm.
I'll probably end up keeping those changes in my local working branches since it helps me validate the types and understand intended behaviour. Even if it doesn't end up in main
.
…sources-Fix-type-of-pre-declared-variables
…sources-Fix-type-of-pre-declared-variables
…sources-Fix-type-of-pre-declared-variables
pkg_resources
: Expose the type of imports and re-exports
import packaging.specifiers | ||
import packaging.requirements | ||
import packaging.markers | ||
import packaging.utils |
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.
Thank you very much for working on this.
This is probably a new occurrence of the same discussion in #3979 (comment).
In that comment, Jason expressed concerns for redundant imports and how this approach makes it cumbersome to code (my interpretation for why that is not desirable: you have to go around modifying multiple portions of multiple files and if you forget to do it in one portion, something is going to fail - kind of shotgun surgery anti-pattern).
I do acknowledge that for type checking, there seems to be no better solution than the double import, but I think this issue is not something we have reached a final decision yet.
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.
There's definitely some pros and cons to any approach (including "leaving it as-is") to this situation.
Of course I have my bias/preference to being able to type the package on par with (or better than) typeshed stubs, but agree we can cross that bridge when there's nothing else left. Leaves more time to brew some ideas and see what it affects.
Setting as draft to make it clear this isn't a priority to review. Will probably end up being the last |
Summary of changes
Removed unusedresource_dir
andresource_dir
pkg_resources
: Remove unused and shadowed variables #4260Removed overridenrun_main
andrun_script
pkg_resources
: Remove unused and shadowed variables #4260Moved declarations of@_call_aside
defined globals closer to where they're defined. And afterResourceManager
&WorkingSet
to avoid forward reference issuespkg_resources
type the declared global variables #4267Typed the 3 globals set byType_declare_state
as notNone
pkg_resources._declare_state
and make it work statically #4258TYPE_CHECKING
block and static importsWorks towards #2345 and a big step towards merging typeshed's
pkg_resources
stubs into setuptoolsPull Request Checklist
newsfragments/
.(See documentation for details)