In a message of Tue, 15 May 2012 16:23:14 +0200, Armin Rigo writes: tons of things that I agree with more or less wholesale, though I think that there is a slightly larger market for Cython in the immediate future ...
Then comes this: >The simplest FFI we know of for a high-level language is LuaJIT's FFI. > If you are interested, read the four pages starting at >http://luajit.org/ext_ffi.html . A crucial design decision was to >avoid making use of tons of objects representing the C types; instead, >the user mostly specifies C types as plain strings, simplifying the >basic API a lot. > >So we would like to propose some design very similar to that one. The >basic public API looks more or less fine to me. There are of course >preferences and topics to discuss, but let's leave that for later. >Most importantly, we would welcome a system where the C declarations >can be parsed either internally or (for more complicated cases) >externally, with the help of a real C compiler. This might include >cases like macros, where the user would need to write (as C code) a >small function calling the macro, and have it compiled when he imports >his Python module. more cool stuff. Sounds great to me. Except that Mike Pell (LuaJit's author) hasn't been cc'd on this note. And so what I would like to know before backing this new idea as clearly the right thing to do, is some statement from him that he is happy with it. Because, dear God, if he had not already existed and made this thing, then *we* would be the people with the best working FFI. And before somebody decided to do things 'our way' (Whichever of the 2 I am thinking of) we would dearly love to get a chance to shout at them -- No NO NO -- our way was an experiment and too messy to be used. The string approach is not messy in the same way as the let-us-make-enough-objects approach is. But unpacking them might lead to other messiness. I'd dearly love to hear from those who use this interface and LuaJIT all the time to hear what they think of it, it's greatest strengths and limitations. But JuaJIT has a nice public mailing list -- why not let them know we are planning to do this and see what they think? Mike Pall I think would be interested and would warn us about problems he has found. Laura _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
