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

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


Branch: CURRENT, Version: 1.11.4, Package name: py27-cffi-1.11.4, 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: d0c4f7d4b6af4c438a17b2f2334f2aa5ff7cc4db
RMD160: 6c84f2ac4a6c90f070f511e440ca6c3ed05763de
Filesize: 426.618 KB

Version history: (Expand)


CVS history: (Expand)


   2018-01-14 12:09:17 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.11.4

v1.11.4:
* Windows: reverted linking with python3.dll, because virtualenv does not make \ 
this DLL available to virtual environments for now. On Windows only, the C \ 
extension modules created by cffi follow for now the standard naming scheme \ 
foo.cp36-win32.pyd, to make it clear that they are regular CPython modules \ 
depending on python36.dll.
   2018-01-12 13:26:00 by Adam Ciarcinski | Files touched by this commit (2) | Package updated
Log message:
py-cffi: updated to 1.11.3

v1.11.3
Fix on CPython 3.x: reading the attributes __loader__ or __spec__ from the \ 
cffi-generated lib modules gave a buggy SystemError. (These attributes are \ 
always None, and provided only to help compatibility with tools that expect them \ 
in all modules.)
More Windows fixes: workaround for MSVC not supporting large literal strings in \ 
C code (from ffi.embedding_init_code(large_string)); and an issue with \ 
Py_LIMITED_API linking with python35.dll/python36.dll instead of python3.dll.
Small documentation improvements.
   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

v1.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

v1.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

v1.11
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.

v1.10

    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
    5.7.
    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
    constants.