Python bindings by default

Stuart McGraw smcg4191 at frii.com
Fri Mar 2 12:23:07 EST 2012


On 03/02/2012 08:08 AM, John Ralls wrote:
> 
> On Mar 2, 2012, at 3:29 AM, Quentin Stafford-Fraser wrote:
> 
>> Hello all - 
>> 
>> I'm wondering how difficult it would be for the Python bindings to be included in the standard distributions?
>> 
>> I suspect that many of the requests on the lists might be solved with a shortish Python plugin, but it's not a useful thing to suggest when most people can't take advantage of it.
>> 
>> I'm on a Mac, and, while I do have the knowledge and tools to go and compile everything from scratch, I haven't yet summoned up the willpower!  Many people would be much worse off than me!
>> 
>> There may be good reasons, of course, why it would make building the distros much harder, but I thought I'd ask!
> 
> For Macs, the reason is that each version of OSX provides a different version of Python*, and the python bindings C library has to link against libpython. So python would have to be included in the bundle, which is already over 100M thanks to having to ship a separate WebKit (one that integrates with Gtk). Worse, any python script that accesses the bindings would have to run the bundled python, not any of the ones provided by the OS.
> 
> *Yes, from Snow Leopard more than one is provided, and everything except Leopard provides 2.6, so if we dropped Leopard support we could do it.

What about using Python's ctypes module to create 
the bindings rather than swig?  Such bindings would 
be independent of the installed Python version I think
at the cost of some runtime efficiency (which would 
not matter if the called API takes relatively much 
more time.)  I think the PyOpenGL bindings made this
change a few years ago, at least in part, for the 
same reason. (http://pyopengl.sourceforge.net/ctypes/development.html)


More information about the gnucash-user mailing list