I think we can instead use ctypes.pointer[ctypes.c_int32] for example. Reference: python/mypy#7540 (comment)

@jmoralez hmmm, that doesn't look right to me.

docker run \
    --rm \
    --entrypoint="" \
    -it python:3.8-slim \
    python -c "import ctypes; print(ctypes.POINTER[ctypes.c_int32])"

Traceback (most recent call last):
File "", line 1, in
TypeError: 'builtin_function_or_method' object is not subscriptable

I think that maybe the comment you found was someone getting lucky (or, I guess, unlucky) with the official type hints for ctypes being inaccurate.

See this from last month: python/typeshed#8351 (comment)

Ah I see, in the stub the lowercase pointer is a class but in ctypes it isn't haha. I think it's ok to go with Any.

Should we switch to ctypes._Pointer with a new mypy release in the future according to python/typeshed#8446 (comment)?

@StrikerRUS I'm nervous about relying on something preceded with a _, since I interpret that as being a private implementation detail that could change.

I want LightGBM's Python code to get the benefits of type-hinting, but I'm worried about the risk of user code being broken because of a change in typeshed.

Just for reference:

Especially given that ctypes._Pointer is actually documented -- it seems like it's not really meant to be a "private" class.
python/typeshed#8446 (comment)

However, I'm OK with Any.

Thanks for pointing out that comment.

Even with that, I'm just nervous about the amount of change happening around this topic (indicated by the issues, you, @jmoralez , and I have linked to) and don't think the benefit of more accurate hints for these small utility functions is worth taking on the risk of incompatibilities of lightgbm with different versions of ctypes.

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.