[pypy-dev] missing things for making PyPy "production" ready (for some value of production)

[David Cournapeau]

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