On Wed, Jul 18, 2018 at 8:18 PM, Radim Řehůřek
wrote:
> Thanks for your feedback everyone. Given the overwhelmingly negative
> response, we'll drop this line of investigation.
>
> If more people bring up the same request in the future (unlikely), feel free
> to reach out to us for some extra set
Thanks for your feedback everyone. Given the overwhelmingly negative
response, we'll drop this line of investigation.
If more people bring up the same request in the future (unlikely), feel
free to reach out to us for some extra set of hands. Given the initial
poking, I still think a "reasonable
Op 17 jul. 2018 om 09:40 heeft Radim Řehůřek het
volgende geschreven:
>
>
> To be honest, I did do some CPython source code staring already. And at least
> for the functions we care about, it wasn't all that painful (PyDict_GetItem
> being the trickiest). Doing this wholesale might be a
[Radim Řehůřek ]
> Thanks Tim. That's one unambiguous answer.
I'm glad that part came across ;-)
> I did consider posting to python-list, but this seemed somewhat
> python-devish.
>
I agree it's on the margin - I don't mind.
Any appetite for documenting which foundational functions are
Thanks Tim. That's one unambiguous answer.
I did consider posting to python-list, but this seemed somewhat
python-devish. Any appetite for documenting which foundational functions
are const-safe in the sense I described? Perhaps we could help. What kind
of analysis, demand or momentum is needed
[Tim]
> > Same as the docs, I use "Python object" to mean a pointer to PyObject.
> In
> that sense, a Py_buffer is no more a "Python object" than, e.g,, is a
> > Py_ssize_t.
>
[Antoine
> Yes, and the payload of an int object is not a "Python object".
> The OP mentioned PyInt_AS_LONG as an
On Tue, 17 Jul 2018 10:59:02 -0500
Tim Peters wrote:
>
> Same as the docs, I use "Python object" to mean a pointer to PyObject. In
> that sense, a Py_buffer is no more a "Python object" than, e.g,, is a
> Py_ssize_t.
Yes, and the payload of an int object is not a "Python object".
The OP
On Tue, Jul 17, 2018 at 4:34 AM, Victor Stinner wrote:
>
> IMHO you need a different approach to implement optimizations. For
> example, use your objects which don't rely on the GIL to be
> consistent. Sadly, I have no experience with that and so cannot
> provide any example.
>
I DO NOT
[Tim]> There is no intention to support GIL-free access to any Python
objects. So
> > that's the contract: "All warranties are null & void if you do just
> about
> > anything while not holding the GIL".
>
[Antoine]
> Actually, accessing a Py_buffer that's been obtained in the regular way
On 17.07.2018 7:18, Radim Řehůřek wrote:
Hi all,
one of our Python projects calls for pretty heavy, low-level
optimizations.
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
2018-07-17 6:18 GMT+02:00 Radim Řehůřek :
> one of our Python projects calls for pretty heavy, low-level optimizations.
>
> 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
On Tue, 17 Jul 2018 00:15:04 -0500
Tim Peters wrote:
> > 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?
>
> There is no intention to support GIL-free access to any Python objects.
[Radim Řehůřek ]
> one of our Python projects calls for pretty heavy, low-level optimizations.
> 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
13 matches
Mail list logo
