Recently, "M.-A. Lemburg" <mal@lemburg.com> said:
> Jack Jansen wrote:
> >
> > Recently, "Martin v. Loewis" <martin@v.loewis.de> said:
> > > > There's a lot of Python objects that are really little more than
> > > > wrappers around an opaque C pointer (plus all the methods to operate
> > > > on it, etc).
> > >
> > > Can you give a few examples? I'm not aware of any such types, off-hand.
> >
> > All the Mac toolbox objects (Windows, Dialogs, Controls, Menus and a
> > zillion more), All the Windows HANDLEs, all the MFC objects (although
> > they might be a bit more difficult), the objects in the X11 and Motif
> > modules, the pyexpat parser object, *dbm objects, dlmodule objects,
> > mpz objects, zlib objects, SGI cl and al objects....
> >
> > Enough examples? :-)
>
> Sounds like you want to introduce a "buffer" interface for these
> objects.
No, that is something completely different. I want a replacement for
PyArg_Parse("O&", funcptr, void**) that has the form
PyArg_Parse("O@", typeobject, void**) and similarly for Py_BuildValue.
Because the typeobject has a Python representation (whereas the
function pointer does not) this would allow modules like struct and
calldll to support objects that have this interface, because these
modules are driven from specifications in Python. There is currently
no way to get from the typeobject to the function pointer needed for
O&.
--
- 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