[Python-Dev] Feature request: better support for "wrapper" objects

[Jack Jansen]

Recently, "Martin v. Loewis" <martin@v.loewis.de> said:
> 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.

Basically correct, but there is no reason why the rewritten version
would accept only WinObj's. ("O@", typeobj, ptr) would call
typeobj->tp_convert(arg[i], ptr)
and the semantics of tp_convert would be '"cast" arg PyObject to
whatever your type is and store the C pointer value for that thing in
ptr'. Or, to make things clearer, WinObj_Type->tp_convert would simply
point to the current WinObj_Convert function.

> > 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?

That would allow you to do the same thing, but rather more error prone
(i.e. I think it is much more of a hack than what I'm trying to get
at). As you noted above WinObj's unfortunately need such a hack, but I
would expect to get rid of it as soon as possible. I really don't like
passing C pointers around in Python integers.

> 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.

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). 
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma Goldman -