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.().t
Hi Matti,
On 25 June 2014 16:10, Matti Picus 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 u
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(...
Hi Matti,
On 25 June 2014 14:47, Matti Picus 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.
___
pypy-dev mailing
(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:
Hi Matti,
First question, what is the relationship of this mail and "PyPy on Windows"?
On 21 June 2014 22:24, Matti Picus 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
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
