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 <cfb...@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@python.org > http://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
