Does/will pypy support cpython's c extension modules?
Subject says it all. Will I be able to use my existing c (c++ actually) modules?
Why not if Cpython can then pypy can ! On 1/23/07, Simon Burton <simon@arrowtheory.com> wrote:
Please no. Porting modules to ctypes is well worth the effort because then they will work with Jython and IronPython as well as CPython and PyPy. IMHO the CPython extension API is the "wrong" way to extend Python and has been since the beginning, not least because it assumes implementation details of the interpreter like reference counting, object layout, etc. James Matthews wrote:
On Mon, 29 Jan 2007 11:07:26 -0800, Sean Lynch <seanl@literati.org> wrote:
If PyPy is to be a practical platform, then it would actually be beneficial for it to support the CPython extension API. The API may be crummy and undesirable in various ways, but it would still help projects moving from another runtime to PyPy if PyPy could load the extension modules they depend on until someone ports them to something better. Whether or not it is a goal for PyPy to be a practical platform right now, I don't know. This seems to be what the original poster is interested in, though, and I assume that if it is not a goal now, it will become one at some point. Jean-Paul
Thats life eh? On 1/29/07, Neal Becker <ndbecker2@gmail.com> wrote:
Tristan Seligmann <mithrandi@mithrandi.za.net> writes:
I guess there's a chance that boost::python is sufficiently declarative that you could make code using it work for PyPy too... don't know the details at all though.
Is it even feasible to wrap a C++ library with ctypes?
I guess it must be possible -- the name mangling rules aren't that hard, really -- but I don't know about feasible. Oh, hmm, templates. They'd be a pain, wouldn't they :-) Cheers, mwh -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp
Tristan Seligmann wrote:
I have the beginnings of an automatic C and ctypes wrapper generator for C++ code. I've been successful generating the C wrapper with namespaces and non-class functions with the user telling the generator how to rename overloaded functions, and my gccxml parser supports pretty much all features of C++ except for templates now, but I still need to work on the output for class-using code and ctypes code output. The idea is to generate C wrappers for every exported function/constructor/class and to recreate the same class structure in Python with the methods calling with ctypes the appropriate C function in the wrapper. I've gotten this far with about eight hours of programming, including writing my gccxml parser, switching to pygccxml, then switching back to my own parser and finishing it when I realized that pygccxml is messy and doesn't properly support function pointers. As for boost::python, you knew you were stuck with CPython when you started, since it doesn't support IronPython or Jython either. However, given a wrapper generator like the one I've started on, you should be able to throw out all the Python-related code and just wrap the pure C++ code. I wish we could just support the gcc 3.4+ (i.e. Itanium) ABI directly, but that would be kind of pointless since VC++ doesn't support it and uses a completely undocumented and unstable ABI. It seems kind of strange to say that PyPy can't be practical without implementing the CPython extension API, since to my knowledge IronPython will not implement it (and Jython never has) and people are afraid that IronPython will be such a great Python alternative that it will fragment the Python community.
Sean Lynch <seanl@literati.org> writes:
Have you seen Armin's autoctypes? https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ Scary code, and a rather different approach :-)
I don't think anyone has quite claimed that; I thought the claim was that supporting the CPython API would make PyPy a practical platform faster, and it's hard to disagree with that. Whether it's worth the effort involved is another question of course :-) The whole "interacting with the outside world" thing is a, probably /the/, most significant thing between here and a practical PyPy. Currently, there is no such thing as a PyPy extension module, and that's something that will need to change. Cheers, mwh -- Richard Gabriel was wrong: worse is not better, lying is better. Languages and systems succeed in the marketplace to the extent that their proponents lie about what they can do. -- Tim Bradshaw, comp.lang.lisp
Michael Hudson wrote:
and it does not work for wrapping C++ code, right?
Just a small addition, to not have wrong impressions: There _are_ PyPy extension modules. They are called mixed modules (since you can mix app-level and interpreter-level code in them). It's just that they are not really extension modules in the sense that you can compile them independently from PyPy and load them as a .so (or whatever) later. Cheers, Carl Friedrich
Carl Friedrich Bolz <cfbolz@gmx.de> writes:
Well, I don't know; it works by compiling snippets of C++ so maybe it has a chance...
Right yes, that's what I meant, thanks for the clarification. Maybe I should emphasized the _extension_ part... Cheers, mwh -- I located the link but haven't bothered to re-read the article, preferring to post nonsense to usenet before checking my facts. -- Ben Wolfson, comp.lang.python
Hi Neal, On Tue, Jan 23, 2007 at 03:29:00PM -0500, Neal Becker wrote:
Subject says it all. Will I be able to use my existing c (c++ actually) modules?
In theory, yes, we could do this. But it would be quite some work so we are focusing on other priorities at the moment. A bientot, Armin.
Why not if Cpython can then pypy can ! On 1/23/07, Simon Burton <simon@arrowtheory.com> wrote:
Please no. Porting modules to ctypes is well worth the effort because then they will work with Jython and IronPython as well as CPython and PyPy. IMHO the CPython extension API is the "wrong" way to extend Python and has been since the beginning, not least because it assumes implementation details of the interpreter like reference counting, object layout, etc. James Matthews wrote:
On Mon, 29 Jan 2007 11:07:26 -0800, Sean Lynch <seanl@literati.org> wrote:
If PyPy is to be a practical platform, then it would actually be beneficial for it to support the CPython extension API. The API may be crummy and undesirable in various ways, but it would still help projects moving from another runtime to PyPy if PyPy could load the extension modules they depend on until someone ports them to something better. Whether or not it is a goal for PyPy to be a practical platform right now, I don't know. This seems to be what the original poster is interested in, though, and I assume that if it is not a goal now, it will become one at some point. Jean-Paul
Thats life eh? On 1/29/07, Neal Becker <ndbecker2@gmail.com> wrote:
Tristan Seligmann <mithrandi@mithrandi.za.net> writes:
I guess there's a chance that boost::python is sufficiently declarative that you could make code using it work for PyPy too... don't know the details at all though.
Is it even feasible to wrap a C++ library with ctypes?
I guess it must be possible -- the name mangling rules aren't that hard, really -- but I don't know about feasible. Oh, hmm, templates. They'd be a pain, wouldn't they :-) Cheers, mwh -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp
Tristan Seligmann wrote:
I have the beginnings of an automatic C and ctypes wrapper generator for C++ code. I've been successful generating the C wrapper with namespaces and non-class functions with the user telling the generator how to rename overloaded functions, and my gccxml parser supports pretty much all features of C++ except for templates now, but I still need to work on the output for class-using code and ctypes code output. The idea is to generate C wrappers for every exported function/constructor/class and to recreate the same class structure in Python with the methods calling with ctypes the appropriate C function in the wrapper. I've gotten this far with about eight hours of programming, including writing my gccxml parser, switching to pygccxml, then switching back to my own parser and finishing it when I realized that pygccxml is messy and doesn't properly support function pointers. As for boost::python, you knew you were stuck with CPython when you started, since it doesn't support IronPython or Jython either. However, given a wrapper generator like the one I've started on, you should be able to throw out all the Python-related code and just wrap the pure C++ code. I wish we could just support the gcc 3.4+ (i.e. Itanium) ABI directly, but that would be kind of pointless since VC++ doesn't support it and uses a completely undocumented and unstable ABI. It seems kind of strange to say that PyPy can't be practical without implementing the CPython extension API, since to my knowledge IronPython will not implement it (and Jython never has) and people are afraid that IronPython will be such a great Python alternative that it will fragment the Python community.
Sean Lynch <seanl@literati.org> writes:
Have you seen Armin's autoctypes? https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ Scary code, and a rather different approach :-)
I don't think anyone has quite claimed that; I thought the claim was that supporting the CPython API would make PyPy a practical platform faster, and it's hard to disagree with that. Whether it's worth the effort involved is another question of course :-) The whole "interacting with the outside world" thing is a, probably /the/, most significant thing between here and a practical PyPy. Currently, there is no such thing as a PyPy extension module, and that's something that will need to change. Cheers, mwh -- Richard Gabriel was wrong: worse is not better, lying is better. Languages and systems succeed in the marketplace to the extent that their proponents lie about what they can do. -- Tim Bradshaw, comp.lang.lisp
Michael Hudson wrote:
and it does not work for wrapping C++ code, right?
Just a small addition, to not have wrong impressions: There _are_ PyPy extension modules. They are called mixed modules (since you can mix app-level and interpreter-level code in them). It's just that they are not really extension modules in the sense that you can compile them independently from PyPy and load them as a .so (or whatever) later. Cheers, Carl Friedrich
Carl Friedrich Bolz <cfbolz@gmx.de> writes:
Well, I don't know; it works by compiling snippets of C++ so maybe it has a chance...
Right yes, that's what I meant, thanks for the clarification. Maybe I should emphasized the _extension_ part... Cheers, mwh -- I located the link but haven't bothered to re-read the article, preferring to post nonsense to usenet before checking my facts. -- Ben Wolfson, comp.lang.python
Hi Neal, On Tue, Jan 23, 2007 at 03:29:00PM -0500, Neal Becker wrote:
Subject says it all. Will I be able to use my existing c (c++ actually) modules?
In theory, yes, we could do this. But it would be quite some work so we are focusing on other priorities at the moment. A bientot, Armin.
participants (10)
-
Armin Rigo -
Carl Friedrich Bolz -
James Matthews -
Jean-Paul Calderone -
Lenard Lindstrom -
Michael Hudson -
Neal Becker -
Sean Lynch -
Simon Burton -
Tristan Seligmann