Well, as far as I can see from where I am, the only real good that can come
from interfacing with PyObject is the capability to write container classes in
C++. On the other hand, it seems that it is not very often needed. For the
case when objects just need to be LINKED from the C++ code as references, pure
python/Rpython abstraction layer that would keep a backup copy of the object
(which can be discarded from the python side) seems like a better idea. The
main benefit is that there will be no refcounting problem and no slate
pointers - if C++ returns some key that is not available then exception can be
raised instead of segfault as with PyObject*. Also, no extra headers will be
needed on C++ side, and the datatype can be an integer. Why not? As far as I
understand, modifying python objects in C++ with pypy is massively stupid.
By the way - the only reason i use C++ in my project is because I have a
massive amount of legacy code that uses several C libraries and Qt, as well as
openGL, so porting that bunch to python can be quite a hassle. The only
problem is that Python side has to send certain requests to C++, those should
be cached, processed and reported back up when done. Obviously, request object
itself could travel along with the request data for code clarity, but there
can just as well be an int. The only problem with ints is the lifetime of the
references in the mapping structure, which would have to be managed explicitly
in such case. If you are interested, I could send you some thoughts on that
issue specifically, as I was planning to do this kind of thing at some point.
BR,
Alex.
tiistai 05 kesäkuu 2012 09:54:25 Armin Rigo kirjoitti:
> Hi Wim,
>
> On Tue, Jun 5, 2012 at 1:53 AM, <wlavrij...@lbl.gov> wrote:
> > Overall, I'm happy enough with the result (I'm going to need handling of
> > PyObject*'s later for my own nefarious purposes).
>
> Maybe we can motivate you to look for and fix inefficiencies in
> cpyext :-) As far as I know it's still fully designed for "it works
> and we don't care about speed". See for example
> https://bugs.pypy.org/issue1121 which tries to push optimizations in
> cpyext but with no-one really interested from the core group.
>
> But IMHO the main slow part that should be optimized (probably by
> being rewritten from scratch) is the correspondance between the proxy
> PyObject structures and the real PyPy objects, which is exactly the
> part that interests you too. It should be possible at least to cope
> with only one dict lookup instead of at least two to do the roundtrip
> "pypy obj -> cpyext obj -> pypy obj".
>
>
> A bientôt,
>
> Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
