Add `__class_getitem__` support to `ctypes.py_object`

[brianschubert]

Feature or enhancement

Proposal:

ctypes.py_object is generic in typeshed, but is not subscriptable at runtime. This can be troublesome for end users, since type checkers will prompt them to supply a generic type argument, but doing so will produce a TypeError at runtime:

>>> import ctypes
>>> ctypes.py_object[int]
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    ctypes.py_object[int]
    ~~~~~~~~~~~~~~~~^^^^^
TypeError: type 'py_object' is not subscriptable

(albeit this is partially mitigated by deferred annotations in 3.14, but TypeError can still pop up if the annotations are ever evaluated)

py_object's typeshed stubs have been stable for a while, and it seems unlikely to be made non-generic in the future. Therefore I propose that __class_getitem__ be added to ctypes.py_object so that it can be subscripted at runtime.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

python/typeshed#13760

Linked PRs

• gh-132168: Add __class_getitem__ to ctypes.py_object #132169

[picnixz]

What's the reason for having ctypes.py_object generic actually? what does ctypes.py_object[int] means? does it mean a PyLongObject?

[sobolevn]

@picnixz see https://github.com/python/typeshed/blob/2b7019b933ac8339e4ae8f4619a2a746446a8532/stdlib/ctypes/__init__.pyi#L253

[brianschubert]

It represents a pointer to an arbitrary Python object. Having it be generic lets you statically track the type of that object. I haven't written enough ctypes code to personally need it, but I imagine it being generic is useful if you need to access py_object.value, or if you need to type-hint a function whose behavior depends on the type of object that py_object is holding. It being generic also seems to be useful to numpy.