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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4