[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