[Cairo] another set of Python bindings

James Henstridge james at daa.com.au
Fri Sep 12 18:31:48 PDT 2003

On 13/09/03 02:43, Bill Spitzak wrote:

>On Thursday 11 September 2003 06:26 pm, James Henstridge wrote:
>>By exposing reference counting operations on cairo_t objects, this
>>particular case would be easy to handle, so that neither the Python code
>>or C code destroy the cairo_t object until both are finished with it.
>Are we talking about cairo "state" objects? Has it been decided that 
>reference-counting the states is necessary?
>If not, it seems that the solution is trivial: have 2 python objects, one 
>which destroys the state on destruction, and the other that doesn't. Have the 
>various calls return the correct type.
This handles the case of making sure Python doesn't step on the toes of 
some C code, however it doesn't cover the reverse.  If the Python 
programmer has one of thise state objects that doesn't own the 
underlying C object, it may be pointing at an object that has been freed.

Adding a reference count solves both of these issues in a much more 
elegant way.

>If there is reference counts, my recommendation is that there be a "increment 
>reference count" call and a "destroy" call. But there should not be any way 
>to find out what the reference count is, or decrement it without possibly 
>destroying it. This will allow the object to be stored remotely, with only an 
>id number transmitted, and allow them to be shared between connections.
Sure.  There is no point in having both a "destroy" and a "unref" in the 
public API.  The object should be destroyed on the last unref.


Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/

More information about the cairo mailing list