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

[Jack Jansen]

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