ctypes is not an acceptable implementation strategy for modules in the standard library?
From http://bugs.python.org/issue16410 Subj?
Aren't there any modules in stdlib that access system API through ctypes? My arguments for ctypes: 1. doesn't require compilation 2. easier to maintain (no C/toolchain knowledge/ownership needed) 3. pure Python is impossible to exploit (unlike pure C) 4. eating your own dogfood helps to make modules complete and notice such silly/critical/timewasting/drivesmemad errors as http://bugs.python.org/issue16376 a few years earlier Maybe it could even help to make ctypes faster (through some caching mechanizm). -- anatoly t.
On 5 Nov, 2012, at 8:31, anatoly techtonik
From http://bugs.python.org/issue16410 Subj?
Aren't there any modules in stdlib that access system API through ctypes?
uuid uses ctypes to access platform APIs.
My arguments for ctypes: 1. doesn't require compilation 2. easier to maintain (no C/toolchain knowledge/ownership needed) 3. pure Python is impossible to exploit (unlike pure C)
That's not not quite true, python code that uses ctypes can still cause buffer overflows and the like when you aren't careful, and adds new failure modes (such as incorrect specification of a C function prototype in the Python code that calls that C function) Ronald
On Mon, 05 Nov 2012 10:31:26 +0300, anatoly techtonik
Aren't there any modules in stdlib that access system API through ctypes?
No. This is a policy. Changing that policy would require a PEP (*after* a discussion on python-ideas...which has probably already happened in the past, I would guess). --David
On Mon, Nov 5, 2012 at 9:31 AM, anatoly techtonik
From http://bugs.python.org/issue16410 Subj?
Aren't there any modules in stdlib that access system API through ctypes?
My arguments for ctypes: 1. doesn't require compilation 2. easier to maintain (no C/toolchain knowledge/ownership needed) 3. pure Python is impossible to exploit (unlike pure C) 4. eating your own dogfood helps to make modules complete and notice such silly/critical/timewasting/drivesmemad errors as http://bugs.python.org/issue16376 a few years earlier
Maybe it could even help to make ctypes faster (through some caching mechanizm). -- anatoly t. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com
Hi anatoly. ctypes comes with it's own set of problems that manifest themselves more or less depending what sort of libary have you tried to wrap. Have you ever tried to use it seriously? The list of my personal issues is available here: http://morepypy.blogspot.com/2012/06/release-01-of-cffi.html The main problem is API vs ABI and the robustness of checks. I would not recommend using ctypes for any of the sdtlib (we actually tried in pypy, it turned out a bit awful). Cheers, fijal
On 2012-11-05, at 10:32 , Ronald Oussoren wrote:
My arguments for ctypes: 1. doesn't require compilation 2. easier to maintain (no C/toolchain knowledge/ownership needed) 3. pure Python is impossible to exploit (unlike pure C)
That's not not quite true, python code that uses ctypes can still cause buffer overflows and the like
Such as segfaulting the interpreter. I seem to reliably segfault everything every time I try to use ctypes.
On 05.11.2012 15:14, Xavier Morel wrote:
Such as segfaulting the interpreter. I seem to reliably segfault everything every time I try to use ctypes.
You can do that with C extensions too, by the way. Apart from that, dependency on ABI is more annoying to maintain across platforms than dependency on API. Function calls with ctypes are also very slow. For C extensions in the stdlib, Cython might be a better choice then ctypes. ctypes might be a good choice if you are to use a DLL on your own computer. Because then you only have one ABI to worry about. Not so for Python's standard library. Sturla
On Mon, Nov 05, 2012 at 03:36:00AM -0800, Victor Stinner wrote:
I'm not sure that ctypes is always available (available on all platforms).
Indeed. Every non-x86 Snakebite platform has pretty serious issues with ctypes. I spent a morning looking into one platform, Solaris 10 on SPARC, and, after building the latest libffi from scratch, it failed more tests than that box chews amps. Trent.
participants (8)
-
anatoly techtonik -
Maciej Fijalkowski -
R. David Murray -
Ronald Oussoren -
Sturla Molden -
Trent Nelson -
Victor Stinner -
Xavier Morel