[Python-Dev] LZMA compression support in 3.3

[Dan Stromberg]

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>