Sean Lynch <[EMAIL PROTECTED]> writes: > 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.
Have you seen Armin's autoctypes? https://codespeak.net/viewvc/user/arigo/hack/pypy-hack/autoctypes/ Scary code, and a rather different approach :-) > 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. 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 _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
