Lenard Lindstrom schrieb:
>  On 21 Nov 2006 at 19:48, Thomas Heller wrote:
>  
> > Lenard Lindstrom schrieb:
> > > Forgive me if this has been discussed before. For Python api 
> > > functions does ctypes assume a py_object return type is a new 
> > > reference and a py_object argument is a borrowed reference? 
> > > PyList_GetItem returns a borrowed reference. PyList_SetItem steals a 
> > > reference. I see no reason to call these functions directly. However, 
> > > since they are accessible from ctypes it makes sense that either it 
> > > can handle them correctly or they are  documented as unsafe to use.
> > 
> > py_object works in the way that one would expect with functions returning
> > new references, and *not* stealing a refcount from the argument.
> > For other functions it is required to adjust the refcount manually
> > with _ctypes.Py_INCREF and _ctypes.Py_DECREF.
> > 
> > When I have time I will document that; patches would of course also
> > be appreciated.
> > 
>  Patch submitted to ctypes at sourceforge.

Lenard, I have looked at your patch (although I was more expecting
a doc patch ;-).

1. I don't like the name py_object_incref (although I don't have a better one).
   IMO the name describes how the object is implemented, not it's purpose.
   Obviously, "py_object_borrowed_or_stolen_reference" is no possibility.

2. It is not possible to accept the patch for Python 2.5 - it is in maintainance
   mode, so no new features like this can be added.  Python 2.6 would be the first
   possibility.

3. Another possibility to have such an object in the current release would be
   to find another way to implement such an object - ideally in a pure Python
   addon module or package.  For handling stolen references as function arguments
   it is easy, just implement a from_param classmethod on this object that does
   an additional Py_INCREF.  Not so easy, if possible at all, for .restype.
   If we were using .errcheck for python api functions returning borrowed references,
   the errcheck function could do the additional Py_INCREF call, but that's not
   so convenient.

4. YAGNI?  Is there a need to call these functions that use borrowed or stolen refs
   at all?  It is my impression that these api functions are only provided for
   somewhat more convenient C programming.  Some of these API's are preprocessor
   macros only, so cannot be called by ctypes anyway.

5. If it really makes sense to call lots of Python api's with ctypes, wouldn't it be
   better to wrap the whole api; in other words, implement a module that wraps the
   python api, assigning correct restype and argtypes attributes to all of them?
   Personally, I don't see a need for it.

Thomas

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ctypes-users mailing list
ctypes-users@[...].net
https://lists.sourceforge.net/lists/listinfo/ctypes-users