[issue45391] 3.10 objects.inv classifies UnionType as data

miss-islington added the comment: New changeset 2c2ee83c4db4dbd54017dc364bbefc70fa75ea5d by Miss Islington (bot) in branch '3.10': bpo-45391: mark UnionType as a class in documentation (GH-28757) https://github.com/python/cpython/commit/2c2ee83c4db4dbd54017dc364bbefc70fa75ea5d --

[issue45391] 3.10 objects.inv classifies UnionType as data

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +28228 pull_request: https://github.com/python/cpython/pull/30004 ___ Python tracker

[issue45391] 3.10 objects.inv classifies UnionType as data

Ken Jin added the comment: New changeset e2cfc89e099b8fad5d8d5bd7f59dadffb6078778 by Bernát Gábor in branch 'main': bpo-45391: mark UnionType as a class in documentation (GH-28757) https://github.com/python/cpython/commit/e2cfc89e099b8fad5d8d5bd7f59dadffb6078778 -- nosy: +kj

[issue45391] 3.10 objects.inv classifies UnionType as data

Change by Dominic Davis-Foster : -- nosy: +dom1310df ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45391] 3.10 objects.inv classifies UnionType as data

gaborjbernat added the comment: 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

[issue45391] 3.10 objects.inv classifies UnionType as data

gaborjbernat added the comment: 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. -- ___ Python tracker

[issue45391] 3.10 objects.inv classifies UnionType as data

Brian Skinn added the comment: Identifiers starting with two uppercase letters returns a HUGE list. >>> pat2 = re.compile(r"([.][A-Z][A-Z])[^.]*$") Filtering down by only those that contain.lower() "type": >>> pprint([obj.name for obj in inv.objects if obj.role == "data" and >>>

[issue45391] 3.10 objects.inv classifies UnionType as data

Brian Skinn added the comment: 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'

[issue45391] 3.10 objects.inv classifies UnionType as data

gaborjbernat added the comment: 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.

[issue45391] 3.10 objects.inv classifies UnionType as data

Łukasz Langa added the comment: On the PR you mention there's more types with this problem. Can we get a full list? -- nosy: +lukasz.langa ___ Python tracker ___

[issue45391] 3.10 objects.inv classifies UnionType as data

gaborjbernat added the comment: 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). -- ___ Python tracker

[issue45391] 3.10 objects.inv classifies UnionType as data

Change by gaborjbernat : -- keywords: +patch pull_requests: +27100 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28757 ___ Python tracker ___

[issue45391] 3.10 objects.inv classifies UnionType as data

New submission from gaborjbernat : It's a class though: ❯ sphobjinv suggest ./objects.inv UnionType :py:data:`types.UnionType` defined as: UnionType = type(int | str) -- assignee: docs@python components: Documentation messages: 403300 nosy: docs@python, gaborjbernat priority: normal