[pypy-dev] Does/will pypy support cpython's c extension modules?

[Michael Hudson]

Sean Lynch <seanl at literati.org> 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