(original) (raw)
On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I'd like to better understand why ctypes is (sometimes) frowned upon.
Is it the brittleness?� Tendency to segfault?
If yes, is there a way of making ctypes less brittle - say, by carefully matching it against a specific version of a .so/.dll before starting to make heavy use of said .so/.dll?
FWIW, I have a partial implementation of a module that does xz from Python using ctypes.� It only does in-memory compression and decompression (not stream compression or decompression to or from a file), because that was all I needed for my current project, but it runs on CPython 2.x, CPython 3.x, and PyPy.� I don't think it runs on Jython, but I've not looked at that carefully - my code falls back on subprocess if ctypes doesn't appear to be all there.
It's at http://stromberg.dnsalias.org/svn/xz\_mod/trunk/xz\_mod.py
On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda <nadeem.vawda@gmail.com> wrote:Note to self: do not comment on python-dev at 2 am, as one's ability
> On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
>> It's acceptable for the Python version to use ctypes in the case of
>> wrapping an existing library, but the Python version should still
>> exist.
>
> I'm not too sure about that - PEP 399 explicitly says that using ctypes is
> frowned upon, and doesn't mention anywhere that it should be used in this
> sort of situation.
to read PEPs correctly apparently suffers :)
Consider my comment withdrawn, you're quite right that PEP 399
actually says this is precisely the case where an exemption is a
reasonable idea. Although I believe it's likely that PyPy will wrap it
with ctypes anyway :)
I'd like to better understand why ctypes is (sometimes) frowned upon.
Is it the brittleness?� Tendency to segfault?
If yes, is there a way of making ctypes less brittle - say, by carefully matching it against a specific version of a .so/.dll before starting to make heavy use of said .so/.dll?
FWIW, I have a partial implementation of a module that does xz from Python using ctypes.� It only does in-memory compression and decompression (not stream compression or decompression to or from a file), because that was all I needed for my current project, but it runs on CPython 2.x, CPython 3.x, and PyPy.� I don't think it runs on Jython, but I've not looked at that carefully - my code falls back on subprocess if ctypes doesn't appear to be all there.
It's at http://stromberg.dnsalias.org/svn/xz\_mod/trunk/xz\_mod.py