> If the goal
> is "only" to pass around PyObjects as black boxes, as fast as
> reasonably possible, then the easiest route would be to not use cpyext
> at all, but instead try to come up with your own mapping logic. This
> looks quite easier for experimentation purposes. And if you end up
> with a good and fast solution we can always try later to reuse it in
> cpyext.
This is precisely the goal for me. The requests in my system are basically a
C++ classes (structs, essentially), that are created and submitted to C++ core
as pointers, they also hold a pointer to the PyObject that submitted the
request. When the request is served, the pyobject can be notified about that
without having to go through any sort of lookups.
>
> 1) a pair of functions to register and unregister a GC pointer that
> lives outside the GC
That might actually be a good idea. In that case a certain object can tell GC
that it wants to have a valid external pointer, and when the object is
destroyed, a __del__ function can remove that registration with GC. If anyone
uses that pointer afterwards it is probably his/her own problem.
I think also that SWIG's idea with c++ side "owning" python objects is rather
lame. Basically, if an object is owned by c++ and not cleaned properly all
kinds of strange things can happen...
BR,
Alex.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
