Re: [Python-Dev] Feature request: better support for "wrapper" objects
All the Mac toolbox objects (Windows, Dialogs, Controls, Menus and a zillion more), All the Windows HANDLEs, all the MFC objects (although they might be a bit more difficult), the objects in the X11 and Motif modules, the pyexpat parser object, *dbm objects, dlmodule objects, mpz objects, zlib objects, SGI cl and al objects....
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, and I'm getting slightly upset that with this subject (again) you appear to start shooting away without trying very hard to understand the issue I'm raising.
Looking at pyexpat.c, I find a few uses of O&, none related to the pyexpat parser object. In zlibmodule.c, I find not a single mentioning of O&, likewise in dlmodule.c, clmodule.c, almodule.c, dbmmodule.c, and now I'm losing interest into verifying more of your examples.
Ok, let me rephrase my list then. The first five items in my list, which you
carefully ignored, are examples of objects that now already make heavy use of
O&. The rest are examples of other objects that wrap a C pointer, and which
could potentially also be opened up to use in struct or calldll.
And to give a complete example of how useful this would be consider the
following. I'll give a mac-centric example, because I don't know enough about
calldll on windows (and I don't think there's a unix version yet).
Assume you're using Python to extend Photoshop. Assume Photoshop has an API to
allow the plugin to get at the screen. Let's assume that there's a C call
extern GrafPtr ps_GetDrawableSurface(void);
to get at the datastructure you need to draw to.
These GrafPtr's are (in Mac/Modules/qd/_Quickdraw.c) wrapped in
Carbon.Qd.GrafPortType objects in Python.
In the current situation, if you would want to wrap this ps_GetDrawableSurface
function you would need to write a C wrapper (which means you would need a C
compiler, etc etc) because you would need to convert the return value with
("O&", GrafObj_new). 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, 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&.
--
- Jack Jansen
From: "Jack Jansen"
And to give a complete example of how useful this would be consider the following. I'll give a mac-centric example, because I don't know enough about calldll on windows (and I don't think there's a unix version yet).
Assume you're using Python to extend Photoshop. Assume Photoshop has an API to allow the plugin to get at the screen. Let's assume that there's a C call extern GrafPtr ps_GetDrawableSurface(void); to get at the datastructure you need to draw to. These GrafPtr's are (in Mac/Modules/qd/_Quickdraw.c) wrapped in Carbon.Qd.GrafPortType objects in Python.
In the current situation, if you would want to wrap this ps_GetDrawableSurface function you would need to write a C wrapper (which means you would need a C compiler, etc etc) because you would need to convert the return value with ("O&", GrafObj_new). 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, 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&.
In Python 2.2, the type object can itself be an instance, and you could call classmethods on it... I'm doing something similar on windows. Thomas
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
participants (3)
-
Jack Jansen
-
Martin v. Loewis
-
Thomas Heller