[pypy-dev] Python FFI

[wlavrijsen at lbl.gov]

Hi,

On Wed, 30 May 2012, Armin Rigo wrote:
> On Tue, May 29, 2012 at 3:49 PM, Robert Zaremba <robert.zaremba at zoho.com> wrote:
>> Whats the problem with cppyy?
>> Why don't extend it rather than build new solution based on pycparser?
> Once again the design goals are different.

right; to Robert: think (conceptually) of cppyy as "c++types". It has so far
been presented in conjunction with Reflex, because the only way that it is
useful for a Python programmer is with an automatic backend to fill in all
necessary details. But for PyPy development purposes, the dispatch (cppyy)
should be seen separately from the specification (Reflex/CINT/Cling/...) of
C++ details.

> Note that the first mail
> in this thread was 15 days ago.  During this time we got a working
> prototype.  I'm sure that it would have taken us 15 days too to even
> figure out how to correctly interface with cppyy

Actually, with Reflex it would be a bit of a hassle (you'd have to stuff the
string in a file, add the required headers, run gccxml, etc., etc.) but with
CINT or Cling, you could just hand the string to the C++ interpreter, run it
and have the bindings generated on the fly.

> not to mention that it requires a C++ compiler

Yes, you simply can't develop something this clean and dependency free for
C++. Of course, it'd work for a subset of C++, but that'd have limited use.

> and --- as far as I know --- cannot handle
> some of the most C-specific ways headers are written, like (ab)uses of
> macros.

Oh yes it can! :) If the compiler can parse it, then bring it on. :) Now I
feel like providing bindings to cpp macro's just to prove that it can be
done (did so in a limited way for PyROOT; haven't bothered for cppyy yet).

Best regards,
            Wim
-- 
WLavrijsen at lbl.gov    --    +1 (510) 486 6411    --    www.lavrijsen.net