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

[Martin v. Loewis]

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

I still fail to see why you need additional ParseTuple support in
calldll.

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

In cdc_call, there is a loop over all arguments, rather than a
ParseTuple call. I don't see how this could change: all arguments are
processed uniformly. Precisely how would you use O@ in there?

Actually, it may be worthwhile to get rid of the PyArg_ParseTuple call
in call_newcall also: for performance reasons, to soften the
dependency on MAXARG, and to give better diagnostics in case of user
errors. There is a loop over argconv, anyway; this loop could have run
over args in the first place.

All you might want to have is additionals slots in type objects; as
Thomas explains, you can have that using just the 2.2 facilities. 

For the specific case of calldll, it seems that a generic mechanism
would be harmful: You want to be absolutely sure that an object is
convertible to a long *for the purposes of API calls*. So I'd even
encourage to create a PyCallDll_RegisterTypeConverter function;
extension types that want to support calldll should register a
conventry and a rvconventry. That approach works for any Python
version.

Regards,
Martin