[LLVMdev] Python bindings in tree

[Gregory Szorc]

There was some talk on IRC last week about desire for Python bindings to
LLVM's Object.h C interface. So, I coded up some and you can now find
some Python bindings in trunk at bindings/python. Currently, the
interfaces for Object.h and Disassembler.h are implemented.

I'd like to stress that things are still rough around the edges, so use
at your own risk. I intend to smooth things over in the next week or so.

I'd really like to fill out the implementation to cover the entirety of
the C interface. Since this will require a lot of work (Core.h is
*massive*), I wanted to run things by the community before I invest too
much time and create something people don't want (I already had to back
out the Python binding to EnhancedDisassembly because I didn't realize
it was deprecated - oops).

Are people interested in more expansive in-tree Python bindings?
Specifically, do we want a Python API for the IR primitives like type
and value that sit lower than the module APIs?

I know there are other Python bindings floating around and from the
perspective of the project, one option is to just tell people to go use
them. But llvm-py seems to have fallen to the wayside (although I did
read a blog post last week where somebody forked it on GitHub and ported
it to work with current SVN HEAD). Having in-tree bindings would
certainly help prevent bit rot (especially if Python test regressions
can mark builds as failed).

Finally, I checked in the new bindings with no review (I was given the
OK over IRC). If someone would be so kind as to review them, I'd really
appreciate the feedback. Also, if I am to commit new features to the
Python bindings, does anyone have a problem with continuing to hold off
on the review [of new code] until after check-in? I think this would
help lower the "time to market" and get more eyes and early testers
using the bindings. From my experience with Clang, people aren't exactly
lining up to review Python patches, so I fear that new Python features
would be sitting in patch purgatory instead of being tested by early
adopters.

Gregory Szorc
gregory.szorc at gmail.com