Dan Stromberg, 27.08.2011 21:58: > On Sat, Aug 27, 2011 at 9:04 AM, Nick Coghlan wrote: >> On Sun, Aug 28, 2011 at 1:58 AM, Nadeem Vawda wrote: >>> On Sat, Aug 27, 2011 at 5:52 PM, Nick Coghlan 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? Maybe unwieldy code and slow execution on CPython? Note that there's a ctypes backend for Cython being written as part of a GSoC, so it should eventually become possible to write C library wrappers in Cython and have it generate a ctypes version to run on PyPy. That, together with the IronPython backend that is on its way, would give you a way to write fast wrappers for at least three of the major four Python implementations, without sacrificing readability or speed in one of them. Stefan
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