News for hackers. Stuff that matters.

A comment on Llvmcpy – Python bindings for LLVM auto-generated from the LLVM-C API.

Re:Llvmcpy – Python bindings for LLVM auto-generated from th... by yjftsjthsd-h on Friday December 16, 2016 @10:27PM (#13199015)
Didn't see in the readme: why "final"? I could see it being considered complete or failed, but it's unclear.
[ Parent | on HN ]
Re:Llvmcpy – Python bindings for LLVM auto-generated from th... by connerbryan on Friday December 16, 2016 @11:45PM (#13199257)
I believe it's because llvmlite is now suggested.

The llvmpy page mentions:

> Warning

> This project has been deprecated and is no longer being actively developed. We strongly suggest migrating to llvmlite.

http://llvmlite.pydata.org/en/latest/

[ Parent | on HN ]
Re:Llvmcpy – Python bindings for LLVM auto-generated from th... by jholman on Saturday December 17, 2016 @05:14AM (#13200072)
Why is this relevant? Are llvmpy and llvmcpy related?
[ Parent | on HN ]
Re:Llvmcpy – Python bindings for LLVM auto-generated from th... by connerbryan on Saturday December 17, 2016 @03:34PM (#13202388)
Oh, my bad. You're right, I got my links mixed up.

aleclm has responded with the correct answer, ignore mine.

[ Parent | on HN ]
Re:Llvmcpy – Python bindings for LLVM auto-generated from th... by aleclm on Saturday December 17, 2016 @12:56AM (#13199492)
Final in the sense that hopefully we won't need a fourth one. It should provide the best performance (since the IR is not re-encoded in Python) and I've tried to make it flexible and future proof. llvmlite currently only supports LLVM 3.8, while I quickly tested llvmcpy with 3.4, 3.8 and 3.9 and works flawlessly.

Still quite alpha, though.

[ Parent | on HN ]