./devel/py-cffi, Foreign Function Interface for Python calling C code

[ CVSweb ] [ Homepage ] [ RSS ] [ Required by ] [ Add to tracker ]

Branch: CURRENT, Version: 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
from Python.

Required to run:
[devel/py-setuptools] [devel/libffi] [lang/python27] [devel/py-cparser]

Required to build:
[devel/py-test] [pkgtools/cwrappers]

Master sites:

SHA1: 8484aba03d1e64367d3110c0e36c1ed052b43f12
RMD160: 8bcdd03716d70fed5a7c25fd0371572356b36aab
Filesize: 408.331 KB

Version history: (Expand)

CVS history: (Expand)

   2017-04-05 17:54:26 by Thomas Klausner | Files touched by this commit (3) | Package updated
Log message:
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,
    non-icc, non-clang)
    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)
Log message:
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) | Package updated
Log message:
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)
Log message:
   2016-09-19 00:05:57 by Thomas Klausner | Files touched by this commit (2) | Package updated
Log message:
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) | Package updated
Log message:
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))
* ffi.from_buffer(bytearray-object)
* C++: "_Bool undefined" fixed
* help(lib), help(lib.myfunc)
   2016-06-08 19:49:20 by Thomas Klausner | Files touched by this commit (15)
Log message: