[Python-Dev] LZMA compression support in 3.3 (original) (raw)

Dan Stromberg drsalists at gmail.com
Sat Aug 27 21:58:39 CEST 2011

On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda <nadeem.vawda at gmail.com> wrote: > On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan <ncoghlan at 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.

Note to self: do not comment on python-dev at 2 am, as one's ability 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110827/d098d4be/attachment.html>

More information about the Python-Dev mailing list