A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-October/114020.html below:

[Python-Dev] Identifier API

[Python-Dev] Identifier APIHrvoje Niksic hrvoje.niksic at avl.com
Tue Oct 11 14:36:56 CEST 2011
On 10/08/2011 04:54 PM, "Martin v. Löwis" wrote:
>       tmp = PyObject_CallMethod(result, "update", "O", other);
>
> would be replaced with
>
>        PyObject *tmp;
>        Py_identifier(update);
>        ...
>        tmp = PyObject_CallMethodId(result,&PyId_update, "O", other);

An alternative I am fond of is to to avoid introducing a new type, and 
simply initialize a PyObject * and register its address.  For example:

   PyObject *tmp;
   static PyObject *s_update;    // pick a naming convention

   PY_IDENTIFIER_INIT(update);
   tmp = PyObject_CallMethodObj(result, s_update, "O", other);

   (but also PyObject_GetAttr(o, s_update), etc.)

PY_IDENTIFIER_INIT(update) might expand to something like:

   if (!s_update) {
     s_update = PyUnicode_InternFromString("update");
     _Py_IdentifierAdd(&s_update);
   }

_PyIdentifierAdd adds the address of the variable to a global set of C 
variables that need to be decreffed and zeroed-out at interpreted shutdown.

The benefits of this approach is:
   * you don't need special "identifier" versions of functions such as
     PyObject_CallMethod. In my example I invented a
     PyObject_CallMethodObj, but adding that might be useful anyway.
   * a lot of Python/C code implements similar caching, often
     leaking strings.

Hrvoje
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4