On Fri, Jan 24, 2014 at 12:41 PM, Armin Rigo <ar...@tunes.org> wrote:
> On Fri, Jan 24, 2014 at 6:56 PM, <wlavrij...@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
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
