I think we shoudl either disable it, or make it be really good: meaning completely skipping the C-call layer, and just making things super simple: def PyListAppend(list, item): list.append(item) There's no point in having it if it's super expensive (IMO). Alex On Sat, Jun 21, 2014 at 1:24 PM, Matti Picus <matti.picus@gmail.com> wrote:
Cpython has a feature that allows you to call c-api functions from python via ctypes.pythonapi It doesn't currently work on pypy, I started to document why not on the disable_pythonapi branch:
``ctypes.pythonapi`` lets you access the CPython C API emulation layer. It does not work on PyPy at the moment, we are missing a ``getfunc`` method for CDLL. Work was begun to refactor the rpython implementation of _rawffi (in pypy/modules/_rawffi/alt) but that project has stalled.
Note that even if it worked, our implementation would not do anything sensible about the GIL and the functions will be named with an extra "Py", for example ``PyPyInt_FromLong()``. Basically, don't use this. Assuming the PyObject pointers you get have any particular fields in any particular order is just going to crash.
but since it is such a bad idea, can we just disable it instead of fixing? In Favor of disabling: no need to extend _rawffi, only remove some code and fix tests Against disabling: another obscure cpython incompatability
Matti
_______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084
Hi Matti, First question, what is the relationship of this mail and "PyPy on Windows"? On 21 June 2014 22:24, Matti Picus <matti.picus@gmail.com> wrote:
``ctypes.pythonapi`` lets you access the CPython C API emulation layer. It does not work on PyPy at the moment, we are missing a ``getfunc`` method for CDLL. Work was begun to refactor the rpython implementation of _rawffi (in pypy/modules/_rawffi/alt) but that project has stalled.
I thought we simply didn't provide ``ctypes.pythonapi``. Seems we do, but I don't want to know what nonsense it does. Just remove it? As Alex says, I don't think it's as simple as adding some method on some CDLL. A bientôt, Armin.
(previous subject mistakenly included reference to "PyPy on Windows") I created a branch disable_pythonapi that copletely removes pythonapi and PyDLL from ctypes, removes sys.dllhandle on windows, and documents these differences to cpython. Should I merge it to default? Matti On 23/06/2014 10:34 AM, Armin Rigo wrote:
Hi Matti,
First question, what is the relationship of this mail and "PyPy on Windows"?
On 21 June 2014 22:24, Matti Picus <matti.picus@gmail.com> wrote:
``ctypes.pythonapi`` lets you access the CPython C API emulation layer. It does not work on PyPy at the moment, we are missing a ``getfunc`` method for CDLL. Work was begun to refactor the rpython implementation of _rawffi (in pypy/modules/_rawffi/alt) but that project has stalled.
I thought we simply didn't provide ``ctypes.pythonapi``. Seems we do, but I don't want to know what nonsense it does. Just remove it? As Alex says, I don't think it's as simple as adding some method on some CDLL.
A bientôt,
Armin.
Assuming I understand correctly, the reason sys.dllhandle exists is that you can do dlopen(NULL) in linux to get a handle to the current process, but not LoadLibrary(NULL). So windows builds provide a handle to the current process DLL as sys.dllhandle, which is then wrapped into ctypes.PyDLL(..., sys.dllhandle) and served up as ctypes.pythonapi. Working backwards from no pythonapi -> no PyDLL -> no sys.dllhandle. Matti On 25/06/2014 5:04 PM, Armin Rigo wrote:
Hi Matti,
On 25 June 2014 14:47, Matti Picus <matti.picus@gmail.com> wrote:
removes sys.dllhandle on windows, Can you explain why removing sys.dllhandle is a good idea? It seems unrelated to the ctypes changes, but maybe it is not.
A bientôt,
Armin.
Hi Matti, On 25 June 2014 16:10, Matti Picus <matti.picus@gmail.com> wrote:
Working backwards from no pythonapi -> no PyDLL -> no sys.dllhandle.
Right, but I'm not sure that it's only used by ctypes and nothing else. If that were the case it would be some private name in the _ctypes module... Also, I'm not sure I understand it correctly, but it seems that on CPython, sys.dllhandle is just an integer, whereas on PyPy so far it is some W_CDLL instance. I wouldn't mind fixing it to be like CPython (then it has nothing to do with cpyext or with _rawffi). A bientôt, Armin.
Googling sys.dllhandle gave me no other uses, the only use case I can of think would involve casting to some kind of ctypes dll and accessing capi (cpyext) capabilites. The original failing test that led me down the path to discover all this was module.cpyext.test.test_cpyext's AppTestApi.().test_dllhandle - note it is in cpyext not sys, there are no tests in sys in pypy nor in cpython that use dllhandle. However, for the mean time, I have restored sys.dllhandle as an int. If it seems OK, feel free to merge into default Matti On 25/06/2014 5:33 PM, Armin Rigo wrote:
Hi Matti,
On 25 June 2014 16:10, Matti Picus<matti.picus@gmail.com> wrote:
Working backwards from no pythonapi -> no PyDLL -> no sys.dllhandle. Right, but I'm not sure that it's only used by ctypes and nothing else. If that were the case it would be some private name in the _ctypes module...
Also, I'm not sure I understand it correctly, but it seems that on CPython, sys.dllhandle is just an integer, whereas on PyPy so far it is some W_CDLL instance. I wouldn't mind fixing it to be like CPython (then it has nothing to do with cpyext or with _rawffi).
A bientôt,
Armin.
participants (3)
-
Alex Gaynor -
Armin Rigo -
Matti Picus