-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
3.10 objects.inv classifies many types as data #89554
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
Comments
It's a class though: ❯ sphobjinv suggest ./objects.inv UnionType defined as: UnionType = type(int | str) |
The issue with the current state this is that intersphinx fails to find types.UnionType in objects.inv because of leaves under the incorrect namespace (data vs class). |
On the PR you mention there's more types with this problem. Can we get a full list? |
Not easily, but, e.g. the EllipsisType is one. I would have to create some script which I haven't done yet. The best would be to create a sphinx plugin that collects entries registered in the doc and displays the discrepancy against the intershpinx object. This way, we could defend against future such issues too. I can give it a go in a few days if no one else wants to do so before that. |
If I understand the problem correctly, these mis-attributions of roles (to 'data' instead of 'class' come about when a thing that is technically a class is defined in source using simple assignment, as with UnionType. Problematic entries will thus have 'data' as role, and their identifiers will be camel-cased. So, as a quick search to identify likely candidates:
# Find entries where the first character after the final period
# is uppercase, and the second character after the final period
# is lowercase.
>>> pat = re.compile(r"([.][A-Z][a-z])[^.]*$")
['_thread.LockType', I would guess those 'ast.PyCF...' objects can be ignored, they appear to be constants? |
Identifiers starting with two uppercase letters returns a HUGE list.
Filtering down by only those that contain.lower() "type":
['errno.EPROTOTYPE', Of these, only 'xml.parsers.expat.XMLParserType' seems to me a likely problem entry. |
I think Brian Skinn script is a rough approximation, but definitely entirely accurate. You'd have to match up what sphinx thinks per doc vs what you import for an accurate view. |
Here's a gist where I managed to detect roughly 140 errors (some looks like potential false positive, so likely the real number is more around 100): https://gist.github.com/gaborbernat/5360badab2125b3f81a3bcbce0e94c2a#file-found_issues-output-L1 This does make a few concessions:
|
As a start, I merged the types.UnionType fix because it's straightforward, but the rest are a little dubious so I'll leave this issue open for now. |
I opened #96996 for these. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: