On 7/18/05, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> David James wrote:
>
> >> Do the python level wrappers for the C level objects hold a
> >>reference to the pool to keep that from happening or something?
> >
> > I'd love to do that! Any ideas on how I could implement it?
>
> Not a clue! ;-)
>
> In theory I imagine the python wrappers for each C level object would do
> an "incrememnt reference count" on the pool's wrapper object in their
> constructor and a "decrement reference count" in their destructor, but
> my knowledge of python extension programming is virtually nil, so I have
> no idea how this would actually be done.
It's easy to put the "increment reference count" on the pool's wrapper
object in the constructor, because there's always a pool object lying
around. On the other hand, it's tough to put "decrement reference
count" in the destructor because SWIG does not generate destructors or
Python proxy objects for 'opaque structs'.
If we let SWIG see the internals of our opaque structs, I'd be able to
write destructors for them. In order to get at the internals of these
structs, I'd need to add include statements for not just our public
header files, but also our internal header files and C files to the C
bindings. If we did this, SWIG would generate higher quality, more
Pythonic bindings because it would understand the internals of
Subversion better. Opinions?
I'd be happy to work on this -- it'll need to wait until we've applied
this patch, though.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 19 18:34:29 2005