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:
-- "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:
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:
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 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:
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:
-- "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:
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:
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 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:
participants (3)
-
Alex Gaynor -
Armin Rigo -
Matti Picus