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

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

Branch: CURRENT, Version: 1.11.2, Package name: py27-cffi-1.11.2, 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:

Required to build:

Master sites:

SHA1: 04d2df85eb1921630b4f9206886737eb37200c19
RMD160: 3db6391bfea5e142aa3c2431090e1b1da95d099b
Filesize: 424.943 KB

Version history: (Expand)

CVS history: (Expand)

   2017-10-10 09:44:12 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: update to 1.11.2

Fix Windows issue with managing the thread-state on CPython 3.0 to 3.5
   2017-10-05 14:18:21 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: update to 1.11.1

Fix tests, remove deprecated C API usage
Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary extensions
Fix for 3.7.0a1+
   2017-09-30 15:09:47 by Adam Ciarcinski | Files touched by this commit (4) | Package updated
Log message:
py-cffi: update to 1.11.0

Support the modern standard types char16_t and char32_t. These work like \ 
wchar_t: they represent one unicode character, or when used as charN_t * or \ 
charN_t[] they represent a unicode string. The difference with wchar_t is that \ 
they have a known, fixed size. They should work at all places that used to work \ 
with wchar_t (please report an issue if I missed something). Note that with \ 
set_source(), you need to make sure that these types are actually defined by the \ 
C source you provide (if used in cdef()).

Support the C99 types float _Complex and double _Complex. Note that libffi \ 
doesn’t support them, which means that in the ABI mode you still cannot call C \ 
functions that take complex numbers directly as arguments or return type.

Fixed a rare race condition when creating multiple FFI instances from multiple \ 
threads. (Note that you aren’t meant to create many FFI instances: in inline \ 
mode, you should write ffi = cffi.FFI() at module level just after import cffi; \ 
and in out-of-line mode you don’t instantiate FFI explicitly at all.)

Windows: using callbacks can be messy because the CFFI internal error messages \ 
show up to stderr—but stderr goes nowhere in many applications. This makes it \ 
particularly hard to get started with the embedding mode. (Once you get started, \ 
you can at least use @ffi.def_extern(onerror=...) and send the error logs where \ 
it makes sense for your application, or record them in log files, and so on.) So \ 
what is new in CFFI is that now, on Windows CFFI will try to open a non-modal \ 
MessageBox (in addition to sending raw messages to stderr). The MessageBox is \ 
only visible if the process stays alive: typically, console applications that \ 
crash close immediately, but that is also the situation where stderr should be \ 
visible anyway.

Progress on support for callbacks in NetBSD.

Functions returning booleans would in some case still return 0 or 1 instead of \ 
False or True. Fixed.

ffi.gc() now takes an optional third parameter, which gives an estimate of the \ 
size (in bytes) of the object. So far, this is only used by PyPy, to make the \ 
next GC occur more quickly (issue 320). In the future, this might have an effect \ 
on CPython too (provided the CPython issue 31105 is addressed).

Add a note to the documentation: the ABI mode gives function objects that are \ 
slower to call than the API mode does. For some reason it is often thought to be \ 
faster. It is not!
   2017-07-03 20:17:45 by Joerg Sonnenberger | Files touched by this commit (6)
Log message:
Use libffi's closure handling based on code from the upstream branch.
Adjust test cases to not use alloca.h on NetBSD. Use a temporary
directory under WRKDIR and allow C++ when test builds are requested.
   2017-07-03 13:08:29 by Thomas Klausner | Files touched by this commit (1)
Log message:
Do not run tests that segfault on NetBSD. Add upstream bug report URL.
   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) | Package updated
Log message:
Updated py-cffi to 1.9.1.


    Structs with variable-sized arrays as their last field: now we
    track the length of the array after ffi.new() is called, just
    like we always tracked the length of ffi.new("int[]", 42). This
    lets us detect out-of-range accesses to array items. This also
    lets us display a better repr(), and have the total size returned
    by ffi.sizeof() and ffi.buffer(). Previously both functions
    would return a result based on the size of the declared structure
    type, with an assumed empty array. (Thanks andrew for starting
    this refactoring.)
    Add support in cdef()/set_source() for unspecified-length arrays
    in typedefs: typedef int foo_t[...];. It was already supported
    for global variables or structure fields.
    I turned in v1.8 a warning from cffi/model.py into an error:
    'enum xxx' has no values explicitly defined: refusing to guess
    which integer type it is meant to be (unsigned/signed, int/long).
    Now Iâm turning it back to a warning again; it seems that
    guessing that the enum has size int is a 99%-safe bet. (But
    not 100%, so it stays as a warning.)
    Fix leaks in the code handling FILE * arguments. In CPython 3
    there is a remaining issue that is hard to fix: if you pass a
    Python file object to a FILE * argument, then os.dup() is used
    and the new file descriptor is only closed when the GC reclaims
    the Python file objectâand not at the earlier time when you
    call close(), which only closes the original file descriptor.
    If this is an issue, you should avoid this automatic convertion
    of Python file objects: instead, explicitly manipulate file
    descriptors and call fdopen() from C (...via cffi).