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:
assignee=Noneclosed_at=Nonecreated_at=<Date2021-10-06.12:20:50.089>labels= ['3.10', 'docs']
title='3.10 objects.inv classifies many types as data'updated_at=<Date2021-12-09.13:22:02.376>user='https://github.com/gaborbernat'
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?
gaborbernat commented on Oct 6, 2021
gaborbernatmannequin
MannequinAuthor
More actions
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.
bskinn commented on Oct 6, 2021
bskinnmannequin
Mannequin
More actions
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])[^.]*$")
>> pprint([obj.name for obj in inv.objects if obj.role == "data" and pat.search(obj.name)])
Of these, only 'xml.parsers.expat.XMLParserType' seems to me a likely problem entry.
gaborbernat commented on Oct 6, 2021
gaborbernatmannequin
MannequinAuthor
More actions
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.
gaborbernat commented on Oct 7, 2021
gaborbernatmannequin
MannequinAuthor
More actions
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):
ignores the difference between function and method; way to many functions are documented as methods and vice-versa to disallow this (or would be a major overhaul)
does not clarifies where to type classes goes - they seem to be a weird in-between a method and a class, satisfying neither - see related discussion on topic from https://bugs.python.org/issue41973
Activity
gaborbernat commented on Oct 6, 2021
It's a class though:
❯ sphobjinv suggest ./objects.inv UnionType
:py:data:`types.UnionType`
defined as:
gaborbernat commented on Oct 6, 2021
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).
ambv commented on Oct 6, 2021
On the PR you mention there's more types with this problem. Can we get a full list?
gaborbernat commented on Oct 6, 2021
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.
bskinn commented on Oct 6, 2021
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:
['_thread.LockType',
'ast.PyCF_ALLOW_TOP_LEVEL_AWAIT',
'ast.PyCF_ONLY_AST',
'ast.PyCF_TYPE_COMMENTS',
'importlib.resources.Package',
'importlib.resources.Resource',
'socket.SocketType',
'types.AsyncGeneratorType',
'types.BuiltinFunctionType',
'types.BuiltinMethodType',
'types.CellType',
'types.ClassMethodDescriptorType',
'types.CoroutineType',
'types.EllipsisType',
'types.FrameType',
'types.FunctionType',
'types.GeneratorType',
'types.GetSetDescriptorType',
'types.LambdaType',
'types.MemberDescriptorType',
'types.MethodDescriptorType',
'types.MethodType',
'types.MethodWrapperType',
'types.NoneType',
'types.NotImplementedType',
'types.UnionType',
'types.WrapperDescriptorType',
'typing.Annotated',
'typing.Any',
'typing.AnyStr',
'typing.Callable',
'typing.ClassVar',
'typing.Concatenate',
'typing.Final',
'typing.Literal',
'typing.NoReturn',
'typing.Optional',
'typing.ParamSpecArgs',
'typing.ParamSpecKwargs',
'typing.Tuple',
'typing.TypeAlias',
'typing.TypeGuard',
'typing.Union',
'weakref.CallableProxyType',
'weakref.ProxyType',
'weakref.ProxyTypes',
'weakref.ReferenceType']
I would guess those 'ast.PyCF...' objects can be ignored, they appear to be constants?
bskinn commented on Oct 6, 2021
Identifiers starting with two uppercase letters returns a HUGE list.
Filtering down by only those that contain.lower() "type":
['errno.EPROTOTYPE',
'locale.LC_CTYPE',
'sqlite3.PARSE_DECLTYPES',
'ssl.CHANNEL_BINDING_TYPES',
'token.TYPE_COMMENT',
'token.TYPE_IGNORE',
'typing.TYPE_CHECKING',
'xml.parsers.expat.XMLParserType']
Of these, only 'xml.parsers.expat.XMLParserType' seems to me a likely problem entry.
gaborbernat commented on Oct 6, 2021
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.
gaborbernat commented on Oct 7, 2021
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:
Fidget-Spinner commented on Dec 9, 2021
New changeset e2cfc89 by Bernát Gábor in branch 'main':
bpo-45391: mark UnionType as a class in documentation (GH-28757)
e2cfc89
39 remaining items
[3.14] gh-89554: Document typing.ParamSpecArgs and ParamSpecKwargs as…
[3.15] gh-89554: Document typing.ParamSpecArgs and ParamSpecKwargs as…
gh-89554: Document _thread.LockType as a class (#150684)
[3.14] gh-89554: Document _thread.LockType as a class (GH-150684) (#1…
[3.15] gh-89554: Document _thread.LockType as a class (GH-150684) (#1…
[3.13] gh-89554: Document _thread.LockType as a class (#150684) (#150786
pythongh-89554: Apply review suggestions for socket roles
gh-89554: Document socket.SocketType as a class (#150683)
[3.15] gh-89554: Document socket.SocketType as a class (GH-150683) (#…
[3.14] gh-89554: Document socket.SocketType as a class (#150683) (#15…
[3.13][3.14] gh-89554: Document socket.SocketType as a class (#150683) (
pythongh-89554: Document socket.SocketType as a class (python#150683)
Preserve old panel anchors via injected HTML spans
[3.13] gh-89554: Document standard type objects in types as classes (G…
[3.14] gh-89554: Document standard type objects in types as classes (G…