Amaury Forgeot d'Arc wrote: > David Cournapeau wrote: >> Martijn Faassen wrote: >>> Yes, this one would be a major challenge. If you can crack it and the >>> PyPy interpreter offers another benefit (an obvious one is speed), you >>> will be in awesome position. If not, the other benefits will have to >>> weigh more strongly. This is definitely one to evolve slowly over time >>> if it's possible at all. >> I don't understand the C++ part. How many useful python modules use C++ >> ? For a start, my understanding is that python itself (interprter + >> stdlib) do not use C++ at all. > > Well, each time you have an interesting C++ library, you have an > interesting python module written in C++. > Two kinds of modules come to my mind: > - wxPython is a good wrapper around the big C++ wxWidgets library. A > cross-platform GUI, > 500 classes, 6000 methods are exposed. Of course the underlying GTK > and Win32 functions are C calls, but do you want to port wxWidgets to > rpython? > - I like to test and automate my own C++ applications with python... I certainly did not mean that there was no interesting C++ library to wrap. But in the context of "making pypy usable for production use", I am not sure this is a priority. To make it short: I can imagine a python implementation with the stdlib to be of some use, and this does not involve C++.
> > Indeed. But there are tools to generate most of the painful code: > Swig, boost::python, and others. > With Swig, you can even subclass C++ classes and override virtual > methods in python. > I wish pypy could do the same. Both methods involve parsing C++, which is not fun. For example, concerning wxwidget, I for once think it would be much easier to wrap gtk than wxwidget (if we think: would be good to have a GUI lib for pypy); incidently, that's how pygtk is generated (some python + scheme code generate the pygtk wrapper around gtk). ctypes can use codegen to automatically wrap C libraries: I have not used it extensively myself, but it is used by some people to wrap non trivial C libraries. > > If I understand correctly, pypy now uses its own "rffi" mechanism (for > "RPython foreign function call"?) to access external C functions. > rffi itself does not use ctypes: when translating a function call, it > is enough to write the C function call, and link with the correct > library. ctypes is used only when executing external functions on top > of CPython: in tests, or in the pypy.py interpreter. > We could do it differently, for example by quickly compiling an > extension module for each function we need. > It could be useful in some cases when ctypes cannot be used. For > example when the C "function" is actually a macro, or a C++ function. > > Should we extend rffi to handle C++? ctypes does not handle C++ for strong (e.g. non trivial) reasons. I mean everybody knows that C++ and C are totally different in this respect. C is easy to use from other languages, C++ is next to impossible. Extending rffi to handle C++ is an enormous task, no ? Again, in the context of making pypy 'production-usable', is it really a priority ? Can't we first do things which do not require C++ support ? David _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev