Re: [Python-Dev] Feature request: better support for "wrapper" objects
Recently, "Martin v. Loewis"
Or, to make things clearer, WinObj_Type->tp_convert would simply point to the current WinObj_Convert function.
So what do you gain with that extension? It seem all that is done is you can replace _Convert by _Type everywhere, with no additional change to the semantics.
Because you can refer to the _Type from Python, that is the whole point of this exercise. And because you can refer to it from Python you can pass it to calldll.newcall and such.
ps_GetDrawableSurface = calldll.newcall(psapilib.ps_GetDrawableSurface, Carbon.Qd.GrafPortType) [...] Not at the moment, but in calldll version 2 there would be. In stead of passing types as "l" or "h" you would pass type objects to newcall(). Newcall() would probably special-case the various ints but for all other types simply call PyArg_Parse(arg, "O@", typeobj, &voidptr).
I still don't understand. In your example, GrafPortType is a return type, not an argument type. So you *have* an anything, and you *want* the GrafPortType. How exactly do you use PyArg_Parse in that scenario?
Sorry, you're right. My example was for a return value, so we're talking Py_BuildValue here. But this situation is equivalent to a GrafPort argument, where PyArg_Parse would be used.
Also, why would you use this extension inside newcall()? I'd rather expect it in ps_GetDrawableSurface.__call__ instead (i.e. when you deal with a specific call, not when you create the callable instance).
Absolutely right, sloppy typing on my part.
--
- Jack Jansen
Because you can refer to the _Type from Python, that is the whole point of this exercise. And because you can refer to it from Python you can pass it to calldll.newcall and such.
I still fail to see why you need additional ParseTuple support in calldll.
Sorry, you're right. My example was for a return value, so we're talking Py_BuildValue here. But this situation is equivalent to a GrafPort argument, where PyArg_Parse would be used.
In cdc_call, there is a loop over all arguments, rather than a ParseTuple call. I don't see how this could change: all arguments are processed uniformly. Precisely how would you use O@ in there? Actually, it may be worthwhile to get rid of the PyArg_ParseTuple call in call_newcall also: for performance reasons, to soften the dependency on MAXARG, and to give better diagnostics in case of user errors. There is a loop over argconv, anyway; this loop could have run over args in the first place. All you might want to have is additionals slots in type objects; as Thomas explains, you can have that using just the 2.2 facilities. For the specific case of calldll, it seems that a generic mechanism would be harmful: You want to be absolutely sure that an object is convertible to a long *for the purposes of API calls*. So I'd even encourage to create a PyCallDll_RegisterTypeConverter function; extension types that want to support calldll should register a conventry and a rvconventry. That approach works for any Python version. Regards, Martin
participants (2)
-
Jack Jansen -
Martin v. Loewis