Diez B. Roggisch
deets at nospam.web.de
Fri Aug 1 01:35:43 CEST 2008
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
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
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.
More information about the Python-list