[pypy-dev] cppyy and callbacks

[Alex Stewart]

On Fri, Jan 24, 2014 at 12:41 PM, Armin Rigo <arigo at tunes.org> wrote:

> On Fri, Jan 24, 2014 at 6:56 PM,  <wlavrijsen at lbl.gov> wrote:
> > By default, there is memory tracking, auto-casting, overloading, template
> > instantiation (with cling; partially with cint), etc. And if that is not
> > desired, a Python layer can be written to do things differently. E.g. to
> > select a specific overload, use the "__dispatch__" function.
>
> So you're basically answering "no" :-)  As you're describing it, cppyy
> is at the "ctypes" level of providing automatic everything and lots of
> options and ways to work around them if they are not wanted.  CFFI is
> at the opposite end of the spectrum on this respect.  But that is for
> C.  I don't have enough practical knowledge of C++ to judge how viable
> a "CPPFFI" would be.
>

Speaking as somebody who is currently using cppyy to build a Python binding
for a large already-existing third-party C++ library, I have to say I think
that moving cppyy in that direction would be a substantial step *backwards*,
making cppyy substantially less valuable and useful.  Please don't do this.

The CFFI way of approaching things works well for C, because C was already
designed as a pretty explicit language to begin with.  The problem,
however, is large portions of the C++ language itself are designed with the
assumption that lots of implicit stuff will be done behind the scenes by
the compiler to make it something a human can actually use.  If you take
that away, C++ becomes much, much more cumbersome and onerous (verging on
completely unusable), and I believe any Python binding that takes that away
would also be similarly cumbersome.

The end result would be something where everyone would *have* to code a
(fairly complex) extra Python interface layer for every single class they
wanted to expose, just to make it usable in Python in a way that
approximates how it's intended to be used in C++ (which as a secondary
issue would probably make it all slower, to boot).

In my opinion, the thing that currently makes cppyy one of the best
cross-language-binding implementations I've ever seen is that it almost
completely eliminates the need to do any of that.  I was able to make a
working binding (that works almost exactly the same way the C++ docs say it
should) for somewhere over 90% of this roughly 150,000 line C++ library
just by writing up a short 30-line XML file and running it through a couple
of utilities to build it.. it's only the last 5-10% or so I'm having to
work on now by hand and write extra interface logic for (and much of that
promises to be fixed with cling).  That is, frankly, amazingly valuable to
me.

In general, I'm a big fan of "explicit is better than implicit", but I do
not believe that that always translates to cross-language bindings.  The
entire point of good language bindings is to do as much of the translation
work automatically as possible so you don't have to write it all yourself
every single time.  If the language you're translating to is designed to do
lots of things implicitly, it's really a practical necessity that the
binding do the same, or it's really only doing half its job.

(I agree that there are a few areas where cppyy could be better at
*allowing* you to be explicit if you want to, but that does not sound like
what you were proposing..  Apologies if I misunderstood anything.)

--Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20140124/32108d1e/attachment-0001.html>