You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
fromctypesimport_CArgObject, _PointerLike# are they correct?_COMError_Details=tuple[str|None, str|None, str|None, int|None, int|None] # Description, Source, HelpFile, HelpContext, scodeclassCOMError(Exception):
"""Raised when a COM method call failed."""hresult: inttext: strdetails: _COMError_Detailsdef__init__(self, hresult: _COMError_HResult, text: str, details: _COMError_Details) ->None: ...
defCopyComPointer(src: _PointerLike, dst: _PointerLike|_CArgObject) ->int: ... # `dst` sometimes maybe return value of `ctypes.byref`."""CopyComPointer(src, dst) -> HRESULT value"""
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].
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.)
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.
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.
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.
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.
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.
Activity
[-]Add `stdlib/ctypes/_ctypes.pyi`[/-][+]Add `stdlib/_ctypes.pyi`[/+][-]Add `stdlib/_ctypes.pyi`[/-][+]Add `stdlib/_ctypes`[/+]Akuli commentedon Aug 20, 2022
Feel free to make a pull request :) There's already lots of other
_foo.pyimodules instdlib/.Some thoughts:
_ctypesas incomplete. This is explained in CONTRIBUTING.md.if sys.platform == "win32"._COMError_Detailsreally be something like("blah", None, None, 123, None)? If it's not possible for some but not all elements to be None, it should betuple[str, str, str, int, int] | tuple[None, None, None, None, None].AlexWaygood commentedon Aug 20, 2022
Most of the stuff that we currently have in
stdlib/ctypes/__init__.pyiis actually re-exported from_ctypesat runtime. If we add_ctypes.pyi, we should eventually move those definitions fromstdlib/ctypes/__init__.pyito_ctypes.pyi, to mimic the runtime more precisely. (That doesn't need to be done in the initial PR adding_ctypes.pyi, though.)junkmd commentedon Aug 20, 2022
@Akuli
Thanks for your response.
I am motivated to contribute to this repository.
I see. I will have to peruse the
CONTRIBUTING.md.There was a post on stack overflow about the lack of
COMErrorin 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.Each element of
_COMError_Detailscan beNone,intorstr.Searching
_ctypes.COMErrorin github often shows(None, None, None, 0, None).But there are also cases where we get
tuple[str, str, str, int, None]ortuple[str, str, None, int, int].COMError.textisNone.Therefore,
tuple[...] | tuple[...]does not represent the actual situation.junkmd commentedon Aug 20, 2022
@AlexWaygood
Thanks for your response.
Regardless of the relationship at runtime, I will create
_ctypesstub using imported stuffs fromctypesfor now.I see that the
_Pointerrecently added to thectypesstub is also originally defined in_ctypes.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.AlexWaygood commentedon Aug 20, 2022
Sounds good to me!
hauntsaninja commentedon Aug 20, 2022
You'll also need to add
_ctypesto https://github.com/python/typeshed/blob/master/stdlib/VERSIONS