-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Merge networkx from python-type-stubs #14038
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
base: main
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…kx-merge-from-python-type-stubs
This comment has been minimized.
This comment has been minimized.
…kx-merge-from-python-type-stubs
This comment has been minimized.
This comment has been minimized.
…kx-merge-from-python-type-stubs
This comment has been minimized.
This comment has been minimized.
…kx-merge-from-python-type-stubs
This comment has been minimized.
This comment has been minimized.
…kx-merge-from-python-type-stubs
This comment has been minimized.
This comment has been minimized.
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Hi! I'm currently experimenting with a semi-automated way of extracting types from docstrings and applying them to stubs. Networkx was on my radar since the docstrings are very detailed and there is definitely some missing coverage. I wanted to check in and see what I should do to avoid causing merge conflicts for you. Should I hold off till all of these changes are merged? Are there directories that you're done with that I can start looking at? |
Hey @yangdanny97 ! These stubs were initially created using https://github.com/gramster/docs2stubs (which you may want to look into for docstring to stubs generation, I think stubgen is starting te have some support as well). Meaning networkx' own docstrings can be quite incorrect at times. Sometimes it's because they're taking shortcuts or using terms they're more familiar with despite being technically incorrect (labeling something a variable-length tuple when it could be any Iterable, labeling an Iterable a list, etc). Sometimes it's using a term that doesn't exist in the type system (for example Array, which may or may not be a sympy matrix or a numpy array). And sometimes it's just flat out wrong. That being said, I'm working on this at a leisurely pace (and have other priorities atm with a big event in September). If we end up with conflicts that would simply mean I'd have to double-check the actual implementation. I wouldn't worry too much about that. |
This PR merges the stubs from https://github.com/microsoft/python-type-stubs/tree/main/stubs/networkx so that removing them from there produce no regression for Pylance users.
I didn't make much effort in completing annotations other than validating what I was copying over.
In doing that I did find quite a handful of incorrect annotations though.
I've already started a few PRs, and will create more that have specific scopes to make it easier to review these changes in chunks. (and will serve as self-review for this big PR). Until then, I'll keep this as draft.