<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 17.07.2018 7:18, Radim Řehůřek wrote:<br>
<blockquote type="cite"
cite="mid:CAAcF8kaF_dWyUzB+pvSwGuE-aymT7RUHy6dAq+qyQh1ycA6TrQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div dir="ltr">Hi all,
<div><br>
one of our Python projects calls for pretty heavy, low-level
optimizations.</div>
<div><br>
</div>
<div>We went down the rabbit hole and determined that having
access to PyList_GET_ITEM(list), PyInt_AS_LONG(int) and
PyDict_GetItem(dict, unicode) on Python objects **outside of
GIL** might be a good-enough solution. The Python objects in
question are guaranteed to live and not be mutated externally
in any way. They're "frozen" and read-only.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
The standard practice if you need to access something outside of GIL
is to get a private C object from it.<br>
For immutable types, you can get a pointer to the underlying data if
the internal representation is compatible with some C type (e.g.
char* <code class="descname">PyBytes_AsString</code><span
class="sig-paren">(</span><a title="PyObject" class="reference
internal">PyObject</a><em> *o</em><span class="sig-paren">)</span>
and FILE* <code class="descname">PyFile_AsFile</code><span
class="sig-paren">(</span><span class="reference internal">PyObject</span><em> *p</em><span
class="sig-paren">) (Py2 only -- in Py3, PyFile no longer wraps
stdio FILE) </span>); otherwise, the C API can produce a copy
(e.g. wchar_t* <code class="descname">PyUnicode_AsWideCharString</code><span
class="sig-paren">(</span><a title="PyObject" class="reference
internal">PyObject</a><em> *unicode</em>, Py_ssize_t<em> *size</em><span
class="sig-paren">)</span> ).<br>
<br>
Though you can call whatever you want outside of GIL (it's not like
we can prevent you), anything that's not officially guaranteed
you're doing on your own risk. Even if it happens to work now, it
can break in unpredictable ways at any point in the future.<br>
<br>
<blockquote type="cite"
cite="mid:CAAcF8kaF_dWyUzB+pvSwGuE-aymT7RUHy6dAq+qyQh1ycA6TrQ@mail.gmail.com">
<div dir="ltr">
<div>Under what conditions is it OK to call these 3 functions on
such objects?</div>
<div><br>
</div>
<div>More generally, what is the CPython 2.7/3.5 contract
regarding (lack of) object mutation, and the need for
reference counting and synchronization via GIL?</div>
<div><br>
</div>
<div>Which C API functions are safe to call on "const" objects?</div>
<div><br>
</div>
<div>Obviously releasing GIL and then calling C API is hacky,
but from initial experiments, it seems to work (see <a
href="https://stackoverflow.com/questions/51351609/can-i-const-access-cpython-objects-without-gil"
moz-do-not-send="true">https://stackoverflow.com/questions/51351609/can-i-const-access-cpython-objects-without-gil</a>).
But I'm wondering if there's a more formal contract around
this behaviour.</div>
<div>
<div><br>
</div>
<div>Cheers,</div>
<div>Radim</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Python-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Python-Dev@python.org">Python-Dev@python.org</a>
<a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru">https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Ivan</pre>
</body>
</html>