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