On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda <nadeem.va...@gmail.com> > wrote: > > On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan <ncogh...@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
_______________________________________________ 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/archive%40mail-archive.com
