Python-bindings misload libpython and misuse PyMem_Free

The libproxy.py section:

# Load libpython (for a cross platform 'free()')

does not work for me...can't find the lib. My python-2.6 shared library is
not in a standard dyld location and is not called libpython2.6 or
libpython26. Even if I did, I might be actually running a
third-party-supplied python in /opt or somewhere else non-dyld-standard, so
this search would find the wrong one entirely. Heck, until recently, my
vendor didn't even supply a shared lib at all (only static). So firstly,
this search approach is non-portable.

Secondly, PyMem_Free is the free() that is used by libpython itself. I
might have an alternate malloc()/free() in some lib that overlays the
normal one (via -L and -l flags, for example), so no guarantee that
libpython's memory-handlers match the ones in my C/C++ realm used by the
compiled libproxy shared lib, and no way to pass standard flags to libproxy
resolve that mis-match. I talked to #python channel on freenode, who
mentioned these problems and that this whole approach is kinda doomed even
if libpython were able to be found reliably.

The clean solution is to rewrite the python bindings for this compiled
library as a compiled in C python module rather than pure .py, so you get
standard C memory handlers (and compiler flags to control them) for
self-consistency.

Original issue reported on code.google.com by dma...@gmail.com on 20 May 2009 at 9:51

binarycrusader / libproxy

Python-bindings misload libpython and misuse PyMem_Free #48