/py-cffi, Foreign Function Interface for Python calling C code
1.10.0, Package name:
py27-cffi-1.10.0, Maintainer: pkgsrc-users
Foreign Function Interface for Python calling C code. The aim of
this project is to provide a convenient and reliable way of calling
C code from Python. The interface is based on LuaJIT's FFI and
follows a few principles:
o The goal is to call C code from Python. You should be able to do
so without learning a 3rd language: every alternative requires
you to learn their own language (Cython, SWIG) or API (ctypes).
So we tried to assume that you know Python and C and minimize
the extra bits of API that you need to learn.
o Keep all the Python-related logic in Python so that you don't
need to write much C code.
o Work either at the level of the ABI (Application Binary Interface)
or the API (Application Programming Interface). Usually, C
libraries have a specified C API but often not an ABI.
o We try to be complete. For now some C99 constructs are not
supported, but all C89 should be, including macros.
o We attempt to support both PyPy and CPython, with a reasonable
path for other Python implementations like IronPython and Jython.
o Note that this project is not about embedding executable C code
in Python, unlike Weave. This is about calling existing C libraries
Required to run:
] Required to build:
Master sites: SHA1:
Version history: (Expand)
- (2017-04-05) Updated to version: py27-cffi-1.10.0
- (2016-11-15) Updated to version: py27-cffi-1.9.1
- (2016-09-22) Updated to version: py27-cffi-1.8.3nb1
- (2016-09-19) Updated to version: py27-cffi-1.8.3
- (2016-09-14) Updated to version: py27-cffi-1.8.2
- (2016-06-13) Updated to version: py27-cffi-1.6.0nb1
CVS history: (Expand)
| 2017-04-05 17:54:26 by Thomas Klausner | Files touched by this commit (3) | |
Updated py-cffi to 1.10.0.
Issue #295: use calloc() directly instead of PyObject_Malloc()+memset()
to handle ffi.new() with a default allocator. Speeds up
ffi.new(large-array) where most of the time you never touch
most of the array.
Some OS/X build fixes (“only with Xcode but without CLT”).
Improve a couple of error messages: when getting mismatched
versions of cffi and its backend; and when calling functions
which cannot be called with libffi because an argument is a
struct that is “too complicated” (and not a struct pointer,
which always works).
Add support for some unusual compilers (non-msvc, non-gcc,
Implemented the remaining cases for ffi.from_buffer. Now all
buffer/memoryview objects can be passed. The one remaining check
is against passing unicode strings in Python 2. (They support
the buffer interface, but that gives the raw bytes behind the
UTF16/UCS4 storage, which is most of the times not what you
expect. In Python 3 this has been fixed and the unicode strings
don’t support the memoryview interface any more.)
The C type _Bool or bool now converts to a Python boolean when
reading, instead of the content of the byte as an integer. The
potential incompatibility here is what occurs if the byte
contains a value different from 0 and 1. Previously, it would
just return it; with this change, CFFI raises an exception in
this case. But this case means “undefined behavior” in C; if
you really have to interface with a library relying on this,
don’t use bool in the CFFI side. Also, it is still valid to use
a byte string as initializer for a bool, but now it must only
contain \x00 or \x01. As an aside, ffi.string() no longer works
on bool (but it never made much sense, as this function stops
at the first zero).
ffi.buffer is now the name of cffi’s buffer type, and ffi.buffer()
works like before but is the constructor of that type.
ffi.addressof(lib, "name") now works also in in-line mode, not
only in out-of-line mode. This is useful for taking the address
of global variables.
Issue #255: cdata objects of a primitive type (integers, floats,
char) are now compared and ordered by value. For example, <cdata
'int' 42> compares equal to 42 and <cdata 'char' b'A'> compares
equal to b'A'. Unlike C, <cdata 'int' -1> does not compare equal
to ffi.cast("unsigned int", -1): it compares smaller, because
-1 < 4294967295.
PyPy: ffi.new() and ffi.new_allocator()() did not record “memory
pressure”, causing the GC to run too infrequently if you call
ffi.new() very often and/or with large arrays. Fixed in PyPy
Support in ffi.cdef() for numeric expressions with + or -.
Assumes that there is no overflow; it should be fixed first
before we add more general support for arbitrary arithmetic on
| 2017-01-28 16:34:19 by Thomas Klausner | Files touched by this commit (1) |
Run self-tests using py.test, better readable output.
Remove mprotect comment; even with it turned off, a segfault happens.
| 2016-11-14 15:31:18 by Thomas Klausner | Files touched by this commit (3) |
| 2016-09-22 08:44:09 by Thomas Klausner | Files touched by this commit (2) | |
Add patch to distinfo and bump PKGREVISION for it.
('make test' still fails with mprotect enabled.)
| 2016-09-22 04:59:36 by Christos Zoulas | Files touched by this commit (1) |
| 2016-09-19 00:05:57 by Thomas Klausner | Files touched by this commit (2) | |
Updated py-cffi to 1.8.3.
* When passing a ``void *`` argument to a function with a different
pointer type, or vice-versa, the cast occurs automatically, like in C.
The same occurs for initialization with ``ffi.new()`` and a few other
places. However, I thought that ``char *`` had the same
property---but I was mistaken. In C you get the usual warning if you
try to give a ``char *`` to a ``char **`` argument, for example.
Sorry about the confusion. This has been fixed in CFFI by giving for
now a warning, too. It will turn into an error in a future version.
| 2016-09-12 09:57:41 by Thomas Klausner | Files touched by this commit (3) | |
Updated py-cffi to 1.8.2.
Tests don't run on MPROTECT enabled systems, and I haven't found
the magic to fix that.
CFFI 1.8.2 has been released. (Versions 1.8 and 1.8.1 are only inside
PyPy 5.4.0 and 5.4.1, which have been released recently.)
Two main changes:
* On CPython 3.x, the C extension modules generated by cffi (not cffi
itself!) are now using CPython's official "limited C API". This means
that the same compiled .so/.dll should work without recompilation on
any version >= 3.2. The name produced by distutils is still
version-specific. To get the version-independent name, you can rename
it manually to ``NAME.abi3.so``, or use the very recent setuptools 26.
* ffi.from_buffer() can now be used on byte strings, getting the
``char *`` address of the C string directly. This was not allowed
because PyPy couldn't support it---we can make the string non-movable,
but the blocker was that the strings in PyPy are not zero-terminated!
So from PyPy 5.4 all strings are allocated with space for one extra
character---an extremely minor overhead---and we write a zero at the
end when ffi.from_buffer() is called. Similarly, when we call
``lib.func("abc")``, PyPy would always make a copy of the string
because the original wasn't zero-terminated; now neither PyPy nor
CPython need to duplicate the string.
cffi 1.7 has been released. (It corresponds to the version that was
released with PyPy 5.3.)
In the main news, the following are now supported:
* ffi.gc(p, None)
* bool(ffi.cast("primitive type", x))
* C++: "_Bool undefined" fixed
* help(lib), help(lib.myfunc)
| 2016-06-08 19:49:20 by Thomas Klausner | Files touched by this commit (15) |
Switch to MASTER_SITE_PYPI.