[pypy-dev] RPython: write generic native library / write CPython C module

Albert Zeyer albzey at googlemail.com
Mon Jun 17 12:47:53 CEST 2013


Oh, that is interesting. I searched a bit around but did not find too
much. Is that what I can see in test_wrapping.py for example
[here](https://bitbucket.org/william_ml_leslie/pypy-effect-analysis/src/4ba135c9c31ec7e256202f8aadf1f0dce24188e0/pypy/translator/c/test/test_wrapping.py?at=0.9.x)?
I also read about the [RPythonic
project](https://code.google.com/p/rpythonic/) which seems to do
something similar.

In my case, I think it would already be fast if for every call with
attributes of immutable objects (strings, numbers, tuples), it would
just copy them and otherwise, it would use some wrapper objects. That
way, RPython would not have to rely on reference counting (except that
the wrapper objects would hold one reference to a native PyObject).
For some other objects, e.g. dicts, it maybe could also copy them if
they are not going to be modified.

I'm interested in trying it out. Or do you think it would be a waste of time?

(Btw., I saw that you have worked at Heinrich Heine Düsseldorf. I'm
just sitting there right now in the library. :))


On Mon, Jun 17, 2013 at 11:38 AM, Carl Friedrich Bolz <cfbolz at gmx.de> wrote:
> On 06/16/2013 01:37 PM, Albert Zeyer wrote:
>>
>> Hi Armin,
>>
>> Well, not quite. I think I know about the limitations and restrictions
>> of RPython. But that is why I think it is especially useful in some
>> cases where I have written some library in Python with some strict
>> subset of Python (or already mostly RPython). I need a native version
>> of the same library and don't really see the point in translating it
>> 1:1 to C by hand.
>
>
> One of the reasons why the RPython project does not care much about
> this use case anymore is that we *had* a way to make CPython
> extensions. It was called the "extension compiler". It turned out to be
> a) extremely annoying to implement b) not very useful in practice. Thus
> a totally frustrating experience overall.
>
> The reasons for slowness was mainly: when compiling RPython code to be
> a C extension module, reference counting is used to reclaim garbage.
> That is extremely slow. Therefore the modules never got the performance
> anybody expected.
>
> Cheers,
>
> Carl Friedrich
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev


More information about the pypy-dev mailing list