[LLVMdev] Python bindings in tree
Gregory Szorc
gregory.szorc at gmail.com
Tue Mar 20 22:07:14 PDT 2012
On Mon, Mar 19, 2012 at 10:44 AM, Anders Waldenborg <anders at 0x63.nu> wrote:
>
> * Auto generated vs manual ctypes declarations.
>
This is purely a cosmetic difference, as we both take the same approach of
registering functions on a global/shared ctypes library instance. I think
automatic is the way to go (just as long as the automatically generated
code is easy to diff when they are regenerated).
* Use of constructor vs "new" static methods.
>
> When using the bindings one never initializes the class manually.
> Instead a "factory" method is used:
>
> mymod = Module.from_file(...)
> mymod = Module.from_data(...)
> mymod = Module.new("foo")
> ity = Type.int(32)
>
> instead of
>
> mymod = Module(file=...)
> mymod = Module(data=...)
> mymod = Module(name="foo")
> ity = IntType(32)
>
Yeah, Module is an example where the number of named arguments is pretty
overwhelming. I was probably going to create static methods for Module
creation. Whether I was going to leave the named arguments on the
constructor is an open issue. I don't think it matters too much.
> Also this makes it consistent with the old defuct llvm-py bindings.
>
I'm not too concerned about this consistency. llvm-py began many years ago.
Assumptions may be different now. I think we should do what makes sense
today. If that is the same great. If not, oh well.
> (partially this also is a consequence of the fact that my bindings
> inherits from c_void_p making it a bit messier)
>
Yup :) Since I started without this inheritance restriction, I was able to
go with what I consider a more "Pythonic" approach: initializers.
> My bindings have python/bindings/lib/llvm
> /tests
> /tools
>
> I do like having the tests outside the dir.
>
I have no major opinion on this.
In related news, I see you have received commit access, Anders.
Congratulations! We just need to figure out this review/module owner
situation...
Gregory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120320/04c8efbe/attachment.html>
More information about the llvm-dev
mailing list