[pypy-dev] GSoC 2015: cpyext project?

wlavrijsen at lbl.gov wlavrijsen at lbl.gov
Wed Dec 3 22:05:02 CET 2014


Toby,

> I've actually put out enquiries to the CERN people about a very similar
> idea, just relating to PyCling -- which is a more general cousin of
> cppyy, from what I can tell -- and so perhaps I could combine your
> expertise with theirs.

I'll just quickly answer here first, get into more detail later on the
private e-mail (although that won't be for today anymore).

We actually have cppyy on CPython with Cling as a backend. The nice thing
about a C++ interpreter is that you can do things like:

  $ python
  Python 2.7.7 (default, Jun 20 2014, 13:47:02) [GCC] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  using my private settings ...
  >>> import cppyy
  >>> from cppyy.gbl import gInterpreter
  >>> gInterpreter.Declare("template<class T> class MyClass { public: T m_val; };")
  True
  >>> from cppyy.gbl import std, MyClass
  >>> v = std.vector(MyClass(int))(1)
  >>> v[0].m_val
  0
  >>> v[0].m_val = 2
  >>> v[0].m_val
  2
  >>>

Clearly, it then also allows to build a 'cppffi' as Armin has asked for.

The catch is that there is a boat load of refactoring to be done. The heavy
lifting in the above module is in libCore, libCling, and libPyROOT, for
example, which are all part of ROOT. (cppyy in PyPy is properly factored.)

When we refer to 'PyCling', we mean the above, but refactored. To first
order, that can be done by stripping all ROOT bits out of PyROOT, but better
would be that it utilizes the same backend as does cppyy in PyPy. (You can
also use the AST directly, in theory, leaving only clang/llvm as dependency,
but we tried that, but it doesn't work. I can get you all the gory details.)

There is more fun to be had then that, though. E.g. cppffi as already
mentioned. But beyond, fully automatically generated bindings get you 95%
of the way only. Yes, you get everything bound, but it smells like C++ and
is sometimes clunky. Pythonizations get you to 99%, e.g. the above session
can be continued like so:

  >>> for m in v:
  ...    print m.m_val
  ...
  2
  >>>

b/c the PyROOT code recognizes the begin()/end() iterator paradigm. Smart,
reflection-based pythonizations are a project in themselves.

Then to get to 100%, requires some proper hooks for the programmer to
fine tune behavior, and although PyROOT has some of that, it's rather ad
hoc (e.g. settings for memory ownership and GIL handling) and I've never
taken to time to think that through, so that could be another fun project.

As said, I'll get to the other e-mail tomorrow.

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


More information about the pypy-dev mailing list