Function References

[Diez B. Roggisch]

squishywaffle at gmail.com schrieb:
> On Jul 31, 10:47 am, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
>> I take the freedom to do so as I see fit - this is usenet...
> 
> Fine, then keep beating a dead horse by replying to this thread with
> things that do nobody any good. It seems like there are a lot better
> way to waste time, though.

You mean like trying to wrap ones head around the rather simple Python C 
API, not getting a callback mechanism implemented?

For the record: I've wrapped C-libs myself, including callbacks. Been 
there, done that, discovered (years later) cytpes, been there for good.

> The Python/C API can get me back further without reliance on third-
> party libraries than ctypes.

You don't consider your own library a third party lib? And unless you're 
wrapping C++, you're opinion is as uninformed as it is wrong.

> It also isn't subject to the quirks that
> ctypes is on platforms other than Windows (the target application runs
> on Windows, Mac, and eventually Linux once the original distributor
> has drivers for the device). I'm not even sure ctypes could load the
> lib/driver the distributor packaged.

Oh please. I'm 98% working on linux & osx. ctypes does a great job on 
these platforms.

Regarding your objections I can only say: whatever the python runtime 
can load because of the underlying ld, ctypes can load. simply because 
they are the same. If *that* was the actual cause of problems, we 
wouldn't even talk about callbacks here.

> So really, I appreciate the option in ctypes, it's good stuff. But
> it's not for this project.

Stop finding lame excuses for not wanting to ditch the work you've done 
in favor of a easier solution. You like your code, you want to keep it, 
you want to discover the intricasies of the Python C API? Be my guest.

But stop embarassing yourself inventing reasons like licensing or linker 
problems you don't support with any facts whatsoever.

> Once again, the original question stands for anyone who has experience
> with the Python/C API callbacks.

You know what? Just for the fun of it, I'll take a stab at it.

  It's easy: Create a "proxy-function" that matches the prototype of the 
c8allback which converts the passed arguments to python values using the 
C-api. Then call the registered python function using 
PyObject_CallFunction.

Convert the return-value back to C, and return it.

Make the function get the PyObject* for the call fetch from a global 
variable you set in the register-callback function, where you also 
register the proxy-function for the first time, or de-register if the 
passed value is None or such.

Have fun.


Diez