> > Could you please try once more, being serious this time? AFAICT, I was
> > asking for examples of types that are parsed by means of O& currently,
> > and do so just to get a void** from the python object.
>
> Shall we try to keep this civil, please? I *am* being serious
Please accept my apologies. I was expecting a single specific example,
and was somewhat surprised to get a list of unspecific ones.
> Ok, let me rephrase my list then. The first five items in my list,
> which you carefully ignored
I have ignored the Mac toolbox objects, since I don't know what they
are, and where to find their source code. I have ignored Windows
HANDLEs, since I don't have PythonWin sources readily available; I
don't know what the X11 and Motif modules are.
Now I've looked somewhat throught the Python source, and found
Mac/Modules/Win/_Winmodule.c:WinObj_SetWindowModality (taking an
arbitrary that seemed to match your description of "Windows"). Is that
one of the examples you were referring to? If so, I still cannot
understand the example. It reads
if (!PyArg_ParseTuple(_args, "lO&",
&inModalKind,
WinObj_Convert, &inUnavailableWindow))
so it appears that you would like to rewrite this as
if (!PyArg_ParseTuple(_args, "lO@",
&inModalKind,
WinObj_Type, &inUnavailableWindow))
Now, if that is how it is supposed to look like: How exactly would it
work? WinObj_Convert accepts None, integers, and WinObjs. It seems
that the rewritten version would only accept WinObj objects.
> extern GrafPtr ps_GetDrawableSurface(void);
[...]
> If we had something like ("O@", typeobject) calldll could
> be extended so you could do something like
> psapilib = calldll.getlibrary(....)
> ps_GetDrawableSurface = calldll.newcall(psapilib.ps_GetDrawableSurface,
> Carbon.Qd.GrafPortType)
>
> (newcall() arguments are funcpointer, return value type, arg1 type, ...)
>
> You cannot do this currently
Please let me try to summarize what this is doing: Given a type object
and a long, create an instance of that type. Is that a correct
analysis of what has to be done?
I see two ways to do that currently:
1. Arrange that it is possible to construct GrafPortType objects from
integers. Then you do
curarg = PyObject_Call(returntype, "l", c_rv);
inside calldll.c:cdc_call
2. Extend the type object to, say, MacType, which offers special support
for calldll, to allow creation of instances given a long value.
> because there is no way to get from the type object (which is the
> only thing you have available in Python) to the functions you need
> to pass to O&.
I completely fail to see how O& fits into the puzzle. AFAICT,
conversion of the return value occurs inside cdc_call. There is no
tuple to parse anyway nearby.
Regards,
Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4