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