Skip to content

Add stdlib/_ctypes #8571

Closed
Closed

Description

@junkmd

My projects use some COM-ffi packages.

I use _ctypes.COMError or _ctypes.CopyComPointer too, but they are not defined in the type stub, so mypy type checker raises Cannot find implementation or library stub for module named "_ctypes" error.

I would like to add type stubs like this.

from ctypes import _CArgObject, _PointerLike
# are they correct?
_COMError_Details = tuple[str | None, str | None, str | None, int | None, int | None]  # Description, Source, HelpFile, HelpContext, scode

class COMError(Exception):
    """Raised when a COM method call failed."""
    hresult: int
    text: str
    details: _COMError_Details

    def __init__(self, hresult: _COMError_HResult, text: str, details: _COMError_Details) -> None: ...


def CopyComPointer(src: _PointerLike, dst: _PointerLike | _CArgObject) -> int: ...  # `dst` sometimes maybe return value of `ctypes.byref`.
    """CopyComPointer(src, dst) -> HRESULT value"""

But other APIs are not clear to me.

  • and where the if sys.platform == "win32": needed.

Any opinions would be appreciated.

Activity

  1. changed the title [-]Add `stdlib/ctypes/_ctypes.pyi`[/-] [+]Add `stdlib/_ctypes.pyi`[/+] on Aug 20, 2022
  2. changed the title [-]Add `stdlib/_ctypes.pyi`[/-] [+]Add `stdlib/_ctypes`[/+] on Aug 20, 2022
  3. Akuli commented on Aug 20, 2022

    @Akuli
    Collaborator

    Feel free to make a pull request :) There's already lots of other _foo.pyi modules in stdlib/.

    Some thoughts:

    • We could mark _ctypes as incomplete. This is explained in CONTRIBUTING.md.
    • Com stuff isn't available on my linux system, so presumably everything except the import should go under if sys.platform == "win32".
    • Can _COMError_Details really be something like ("blah", None, None, 123, None)? If it's not possible for some but not all elements to be None, it should be tuple[str, str, str, int, int] | tuple[None, None, None, None, None].
  4. AlexWaygood commented on Aug 20, 2022

    @AlexWaygood
    Member

    Most of the stuff that we currently have in stdlib/ctypes/__init__.pyi is actually re-exported from _ctypes at runtime. If we add _ctypes.pyi, we should eventually move those definitions from stdlib/ctypes/__init__.pyi to _ctypes.pyi, to mimic the runtime more precisely. (That doesn't need to be done in the initial PR adding _ctypes.pyi, though.)

  5. junkmd commented on Aug 20, 2022

    @junkmd
    ContributorAuthor

    @Akuli

    Thanks for your response.
    I am motivated to contribute to this repository.

    • We could mark _ctypes as incomplete. This is explained in CONTRIBUTING.md.

    I see. I will have to peruse the CONTRIBUTING.md.

    • Com stuff isn't available on my linux system, so presumably everything except the import should go under if sys.platform == "win32".

    There was a post on stack overflow about the lack of COMError in a linux environment.
    https://stackoverflow.com/questions/37161560/importerror-cannot-import-name-comerror-in-python

    I will use if sys.platform == "win32" when defining COM related objects in stubs.

    • Can _COMError_Details really be something like ("blah", None, None, 123, None)? If it's not possible for some but not all elements to be None, it should be tuple[str, str, str, int, int] | tuple[None, None, None, None, None].

    Each element of _COMError_Details can be None, int or str.

    Searching _ctypes.COMError in github often shows (None, None, None, 0, None).
    But there are also cases where we get tuple[str, str, str, int, None] or tuple[str, str, None, int, int].

    Therefore, tuple[...] | tuple[...] does not represent the actual situation.

  6. junkmd commented on Aug 20, 2022

    @junkmd
    ContributorAuthor

    @AlexWaygood

    Thanks for your response.

    Most of the stuff that we currently have in stdlib/ctypes/__init__.pyi is actually re-exported from _ctypes at runtime. If we add _ctypes.pyi, we should eventually move those definitions from stdlib/ctypes/__init__.pyi to _ctypes.pyi, to mimic the runtime more precisely. (That doesn't need to be done in the initial PR adding _ctypes.pyi, though.)

    Regardless of the relationship at runtime, I will create _ctypes stub using imported stuffs from ctypes for now.

    I see that the _Pointer recently added to the ctypes stub is also originally defined in _ctypes.

    Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ctypes
    >>> ctypes._Pointer
    <class '_ctypes._Pointer'>

    But I don't want to make it perfect from the beginning, I want to make it my first priority to get out of the situation where Cannot find ... module named "_ctypes" is displayed for now.

  7. AlexWaygood commented on Aug 20, 2022

    @AlexWaygood
    Member

    @AlexWaygood

    Thanks for your response.

    Most of the stuff that we currently have in stdlib/ctypes/__init__.pyi is actually re-exported from _ctypes at runtime. If we add _ctypes.pyi, we should eventually move those definitions from stdlib/ctypes/__init__.pyi to _ctypes.pyi, to mimic the runtime more precisely. (That doesn't need to be done in the initial PR adding _ctypes.pyi, though.)

    Regardless of the relationship at runtime, I will create _ctypes stub using imported stuffs from ctypes for now.

    I see that the _Pointer recently added to the ctypes stub is also originally defined in _ctypes.

    Python 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ctypes
    >>> ctypes._Pointer
    <class '_ctypes._Pointer'>

    But I don't want to make it perfect from the beginning, I want to make it my first priority to get out of the situation where Cannot find ... module named "_ctypes" is displayed for now.

    Sounds good to me!

  8. hauntsaninja commented on Aug 20, 2022

    @hauntsaninja
    Collaborator
  9. added
    stubs: incompleteAnnotations or sub-modules missing from an existing package or module
    on Aug 20, 2022
  10. linked a pull request that will close this issueadd `_ctypes.pyi` #8582on Aug 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    stubs: incompleteAnnotations or sub-modules missing from an existing package or module

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions