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
{{ message }}
Repository navigation
The constructor of _FuncPointer can accept None to paramflags and Structure to iid in runtime. #8968
i analysed the issue and have few questions to ask.
_pointer[_ct] is generally a optional interface identifier to extend the error tracking.. why _cdata in place of it. _cdata is generally a base class for ctype data types.
structure, itself is a subclass of __StructUnionBase and it is subclass of _cdata. then what is the iid in this case?
I am new a new contributor to this repository and need your help to understand the functional thought behind the changes.
your help definitely guide me to get the better understanding..
@junkmd
you are right iid should be structure type as it is taking GUID interface value. And GUID is the subclass of structure. we can update the iid to structure class.
however we have look for documentation also.please advise
I am not familiar with C, but from the conditional branching of the overloading process, I can interpret it to accept None for paramflags or its elements, or _CData or None for iid.
@junkmd
i went through the above shared link..i am ok with paramflags as tuple or None..regarding iid -
self = (PyCFuncPtrObject *)GenericPyCData_new(type, args, kwds);
self->index = index + 0x1000;
self->paramflags = Py_XNewRef(paramflags);
if (iid_len == sizeof(GUID))
self->iid = iid;
return (PyObject *)self;
here, PyCFuncPtrObject* is converting the returrning pyobject to ctype and storing to self.then setting the each value, including iid in ctype. and finally. converting the self to pyObject and return..
from these inference, you are deriving that iid should be cData or None. am i right?
here 2 arguments are given however in _PF 3 arguments..though union wise it looks same. Will it not create any problem?
will such changes not impact other packages? otherwise we have to looks where it is being used.
This is contained in _UnionT[tuple[int], tuple[int, str | None], tuple[int, str | None, Any]].
The purpose of this change is to ensure that type checking does not cause an error if it is safe to pass it as an argument at runtime.
This change "allows more types than previously allowed". It does not "disallow types that were previously allowed”.
So the existing code should not cause any errors by the type checker.
I think this issue should be addressed after the class definitions have been moved to _ctypes.pyi and names have been changed to CFuncPtr.
Please see #10132.
Activity
AmberAnsari89 commentedon Nov 3, 2022
hi,
i want to work on it.please assign to me if nobody is working on it.
junkmd commentedon Nov 3, 2022
@AmberAnsari89
Hi
Ok, I'll leave it for you.
I also noticed that
iidcan takeNone, so please take that into consideration as well.AmberAnsari89 commentedon Nov 8, 2022
i analysed the issue and have few questions to ask.
I am new a new contributor to this repository and need your help to understand the functional thought behind the changes.
your help definitely guide me to get the better understanding..
thanks
Amber
junkmd commentedon Nov 13, 2022
@AmberAnsari89
see this code snippet. This is available in runtime.
So I think that
_FuncPointershould be changed as follows.junkmd commentedon Nov 13, 2022
@AmberAnsari89
This part is closely tied to the C implementation.
I posted this issue because it doesn't make sense to me that the code that runs at runtime has an error in the type checker.
I haven't read that much of the C implementation code and wanted to get the views of anyone familiar with the
ctypesimplementation.AmberAnsari89 commentedon Nov 14, 2022
@junkmd
you are right iid should be structure type as it is taking GUID interface value. And GUID is the subclass of structure. we can update the iid to structure class.
however we have look for documentation also.please advise
AmberAnsari89 commentedon Nov 14, 2022
https://github.com/enthought/comtypes/blob/5f5429fb8dd62e6f159baadb0d4d5a69b8cdeeec/comtypes/__init__.py#L798-L819
junkmd commentedon Nov 15, 2022
@AmberAnsari89
I have read the C implementation.
I am not familiar with C, but from the conditional branching of the overloading process, I can interpret it to accept
Noneforparamflagsor its elements, or_CDataorNoneforiid.https://github.com/python/cpython/blob/50b0415127009119882e32377d25a4d191088a76/Modules/_ctypes/_ctypes.c#L3377-L3440
https://github.com/python/cpython/blob/50b0415127009119882e32377d25a4d191088a76/Modules/_ctypes/_ctypes.c#L3588-L3612
AmberAnsari89 commentedon Nov 16, 2022
@junkmd
i went through the above shared link..i am ok with paramflags as tuple or None..regarding iid -
self = (PyCFuncPtrObject *)GenericPyCData_new(type, args, kwds);
self->index = index + 0x1000;
self->paramflags = Py_XNewRef(paramflags);
if (iid_len == sizeof(GUID))
self->iid = iid;
return (PyObject *)self;
here, PyCFuncPtrObject* is converting the returrning pyobject to ctype and storing to self.then setting the each value, including iid in ctype. and finally. converting the self to pyObject and return..
from these inference, you are deriving that iid should be cData or None. am i right?
thanks
junkmd commentedon Nov 16, 2022
@AmberAnsari89
Yes, I think you're right.
AmberAnsari89 commentedon Nov 17, 2022
thank you..
i will do the changes.
AmberAnsari89 commentedon Nov 20, 2022
i did the changes and below issue i got while performing pulling request..
comtypes (https://github.com/enthought/comtypes)
AmberAnsari89 commentedon Nov 20, 2022
the type hints of paramflag is different from _functPointer overload in comtypes
junkmd commentedon Nov 20, 2022
@AmberAnsari89
I think the following
_PFneeds to be changed as well.typeshed/stdlib/ctypes/__init__.pyi
Line 89 in dc7fdc6
AmberAnsari89 commentedon Nov 21, 2022
Optional[Tuple[Union[Tuple[int, Optional[str]], Tuple[int, Optional[str], Any]], ...]]
here 2 arguments are given however in _PF 3 arguments..though union wise it looks same. Will it not create any problem?
will such changes not impact other packages? otherwise we have to looks where it is being used.
Thanks
junkmd commentedon Nov 22, 2022
@AmberAnsari89
The
Unions ofcomtypesare written in a legacy way for backward compatibility and is non-intuitive compared to theA | Bintypeshed.https://github.com/enthought/comtypes/blob/30523b53fbd5560d5bde2e722607c860cdf743dd/comtypes/_memberspec.py#L11-L13
The
ParamFlagTypeofcomtypesin thetypeshedwriting style would be the following.This is contained in
_UnionT[tuple[int], tuple[int, str | None], tuple[int, str | None, Any]].The purpose of this change is to ensure that type checking does not cause an error if it is safe to pass it as an argument at runtime.
This change "allows more types than previously allowed". It does not "disallow types that were previously allowed”.
So the existing code should not cause any errors by the type checker.
junkmd commentedon May 3, 2023
I think this issue should be addressed after the class definitions have been moved to
_ctypes.pyiand names have been changed toCFuncPtr.Please see #10132.
junkmd commentedon May 7, 2023
@AmberAnsari89
The definitions of these constructors have been moved to
_ctypes.pyiand the code has changed a lot since I first posted this issue.This issue has also not moved for about 6 months.
I will write a PR about this.
Thank you for your cooperation.
junkmd commentedon May 7, 2023
I close this because #10155 is merged.
Thank you.
AlexWaygood commentedon May 7, 2023
Thank you for all your work on ctypes stubs, @junkmd!