head 1.14; access; symbols pkgsrc-2026Q3:1.14.0.2 pkgsrc-2026Q3-base:1.14 pkgsrc-2026Q2:1.13.0.6 pkgsrc-2026Q2-base:1.13 pkgsrc-2026Q1:1.13.0.4 pkgsrc-2026Q1-base:1.13 pkgsrc-2025Q4:1.13.0.2 pkgsrc-2025Q4-base:1.13 pkgsrc-2025Q3:1.12.0.4 pkgsrc-2025Q3-base:1.12 pkgsrc-2025Q2:1.12.0.2 pkgsrc-2025Q2-base:1.12 pkgsrc-2025Q1:1.11.0.12 pkgsrc-2025Q1-base:1.11 pkgsrc-2024Q4:1.11.0.10 pkgsrc-2024Q4-base:1.11 pkgsrc-2024Q3:1.11.0.8 pkgsrc-2024Q3-base:1.11 pkgsrc-2024Q2:1.11.0.6 pkgsrc-2024Q2-base:1.11 pkgsrc-2024Q1:1.11.0.4 pkgsrc-2024Q1-base:1.11 pkgsrc-2023Q4:1.11.0.2 pkgsrc-2023Q4-base:1.11 pkgsrc-2023Q3:1.8.0.38 pkgsrc-2023Q3-base:1.8 pkgsrc-2023Q2:1.8.0.36 pkgsrc-2023Q2-base:1.8 pkgsrc-2023Q1:1.8.0.34 pkgsrc-2023Q1-base:1.8 pkgsrc-2022Q4:1.8.0.32 pkgsrc-2022Q4-base:1.8 pkgsrc-2022Q3:1.8.0.30 pkgsrc-2022Q3-base:1.8 pkgsrc-2022Q2:1.8.0.28 pkgsrc-2022Q2-base:1.8 pkgsrc-2022Q1:1.8.0.26 pkgsrc-2022Q1-base:1.8 pkgsrc-2021Q4:1.8.0.24 pkgsrc-2021Q4-base:1.8 pkgsrc-2021Q3:1.8.0.22 pkgsrc-2021Q3-base:1.8 pkgsrc-2021Q2:1.8.0.20 pkgsrc-2021Q2-base:1.8 pkgsrc-2021Q1:1.8.0.18 pkgsrc-2021Q1-base:1.8 pkgsrc-2020Q4:1.8.0.16 pkgsrc-2020Q4-base:1.8 pkgsrc-2020Q3:1.8.0.14 pkgsrc-2020Q3-base:1.8 pkgsrc-2020Q2:1.8.0.12 pkgsrc-2020Q2-base:1.8 pkgsrc-2020Q1:1.8.0.8 pkgsrc-2020Q1-base:1.8 pkgsrc-2019Q4:1.8.0.10 pkgsrc-2019Q4-base:1.8 pkgsrc-2019Q3:1.8.0.6 pkgsrc-2019Q3-base:1.8 pkgsrc-2019Q2:1.8.0.4 pkgsrc-2019Q2-base:1.8 pkgsrc-2019Q1:1.8.0.2 pkgsrc-2019Q1-base:1.8 pkgsrc-2018Q4:1.7.0.10 pkgsrc-2018Q4-base:1.7 pkgsrc-2018Q3:1.7.0.8 pkgsrc-2018Q3-base:1.7 pkgsrc-2018Q2:1.7.0.6 pkgsrc-2018Q2-base:1.7 pkgsrc-2018Q1:1.7.0.4 pkgsrc-2018Q1-base:1.7 pkgsrc-2017Q4:1.7.0.2 pkgsrc-2017Q4-base:1.7 pkgsrc-2017Q3:1.6.0.6 pkgsrc-2017Q3-base:1.6 pkgsrc-2017Q2:1.6.0.2 pkgsrc-2017Q2-base:1.6 pkgsrc-2017Q1:1.5.0.6 pkgsrc-2017Q1-base:1.5 pkgsrc-2016Q4:1.5.0.4 pkgsrc-2016Q4-base:1.5 pkgsrc-2016Q3:1.5.0.2 pkgsrc-2016Q3-base:1.5 pkgsrc-2016Q2:1.4.0.4 pkgsrc-2016Q2-base:1.4 pkgsrc-2016Q1:1.4.0.2 pkgsrc-2016Q1-base:1.4 pkgsrc-2015Q4:1.3.0.6 pkgsrc-2015Q4-base:1.3 pkgsrc-2015Q3:1.3.0.4 pkgsrc-2015Q3-base:1.3 pkgsrc-2015Q2:1.3.0.2 pkgsrc-2015Q2-base:1.3 pkgsrc-2015Q1:1.2.0.12 pkgsrc-2015Q1-base:1.2 pkgsrc-2014Q4:1.2.0.10 pkgsrc-2014Q4-base:1.2 pkgsrc-2014Q3:1.2.0.8 pkgsrc-2014Q3-base:1.2 pkgsrc-2014Q2:1.2.0.6 pkgsrc-2014Q2-base:1.2 pkgsrc-2014Q1:1.2.0.4 pkgsrc-2014Q1-base:1.2 pkgsrc-2013Q4:1.2.0.2 pkgsrc-2013Q4-base:1.2; locks; strict; comment @# @; 1.14 date 2026.07.10.09.42.35; author adam; state Exp; branches; next 1.13; commitid COo2aJNwEwFlE5NG; 1.13 date 2025.09.21.15.31.05; author wiz; state Exp; branches; next 1.12; commitid tQGLcogbOgKUXAbG; 1.12 date 2025.04.12.09.50.45; author adam; state Exp; branches; next 1.11; commitid r8Wgjj4HroY0iKQF; 1.11 date 2023.11.05.13.44.36; author wiz; state Exp; branches; next 1.10; commitid utfL2HKnxEMrqqLE; 1.10 date 2023.10.29.18.32.21; author wiz; state Exp; branches; next 1.9; commitid t6eBL4ynPrOafyKE; 1.9 date 2023.10.04.21.51.44; author adam; state Exp; branches; next 1.8; commitid ilu8LPllnnvl9mHE; 1.8 date 2019.02.16.23.37.23; author adam; state Exp; branches; next 1.7; commitid VnsNSibp10sn53cB; 1.7 date 2017.09.30.13.09.47; author adam; state Exp; branches; next 1.6; commitid kOVXplFQEluxOd9A; 1.6 date 2017.04.05.15.54.26; author wiz; state Exp; branches; next 1.5; commitid 064YAsEZSVYWrmMz; 1.5 date 2016.09.12.07.57.41; author wiz; state Exp; branches; next 1.4; commitid oxFzvjMyb0mUoYlz; 1.4 date 2016.01.18.22.55.13; author wiz; state Exp; branches; next 1.3; commitid pXnRtULPfwfa1tRy; 1.3 date 2015.05.28.07.06.32; author wiz; state Exp; branches; next 1.2; commitid f1sLY1UYA9M3kbny; 1.2 date 2013.11.26.14.04.49; author wiz; state Exp; branches; next 1.1; commitid oMHgPc6cAWQEfNex; 1.1 date 2013.09.30.17.19.59; author wiz; state Exp; branches; next ; commitid dr6yaWn6Ndieau7x; desc @@ 1.14 log @py-cffi: updated to 2.1.0 2.1.0 Added the cffi-gen-src command-line tool (also invocable as python -m cffi.gen_src), which generates CFFI C extension source code, so that a build backend such as meson-python can build the extension. See Generating C Sources for CFFI Extensions for details. Integrated from the cffi-buildtool project by Rose Davidson. Added support for arm64 iOS wheels. Dropped support for Python 3.9. Added support for Python 3.15 and support for C extensions generated by CFFI to target the new abi3t free-threaded ABI. Avoid crashes inside of __delitem__. Avoid “string too big” error under MSVC. Fix mingw builds. @ text @@@comment $NetBSD: PLIST,v 1.13 2025/09/21 15:31:05 wiz Exp $ bin/cffi-gen-src-${PYVERSSUFFIX} ${PYSITELIB}/${WHEEL_INFODIR}/METADATA ${PYSITELIB}/${WHEEL_INFODIR}/RECORD ${PYSITELIB}/${WHEEL_INFODIR}/WHEEL ${PYSITELIB}/${WHEEL_INFODIR}/entry_points.txt ${PYSITELIB}/${WHEEL_INFODIR}/licenses/LICENSE ${PYSITELIB}/${WHEEL_INFODIR}/top_level.txt ${PYSITELIB}/_cffi_backend.so ${PYSITELIB}/cffi/__init__.py ${PYSITELIB}/cffi/__init__.pyc ${PYSITELIB}/cffi/__init__.pyo ${PYSITELIB}/cffi/_cffi_errors.h ${PYSITELIB}/cffi/_cffi_gen_src.py ${PYSITELIB}/cffi/_cffi_gen_src.pyc ${PYSITELIB}/cffi/_cffi_gen_src.pyo ${PYSITELIB}/cffi/_cffi_include.h ${PYSITELIB}/cffi/_embedding.h ${PYSITELIB}/cffi/_imp_emulation.py ${PYSITELIB}/cffi/_imp_emulation.pyc ${PYSITELIB}/cffi/_imp_emulation.pyo ${PYSITELIB}/cffi/_shimmed_dist_utils.py ${PYSITELIB}/cffi/_shimmed_dist_utils.pyc ${PYSITELIB}/cffi/_shimmed_dist_utils.pyo ${PYSITELIB}/cffi/api.py ${PYSITELIB}/cffi/api.pyc ${PYSITELIB}/cffi/api.pyo ${PYSITELIB}/cffi/backend_ctypes.py ${PYSITELIB}/cffi/backend_ctypes.pyc ${PYSITELIB}/cffi/backend_ctypes.pyo ${PYSITELIB}/cffi/cffi_opcode.py ${PYSITELIB}/cffi/cffi_opcode.pyc ${PYSITELIB}/cffi/cffi_opcode.pyo ${PYSITELIB}/cffi/commontypes.py ${PYSITELIB}/cffi/commontypes.pyc ${PYSITELIB}/cffi/commontypes.pyo ${PYSITELIB}/cffi/cparser.py ${PYSITELIB}/cffi/cparser.pyc ${PYSITELIB}/cffi/cparser.pyo ${PYSITELIB}/cffi/error.py ${PYSITELIB}/cffi/error.pyc ${PYSITELIB}/cffi/error.pyo ${PYSITELIB}/cffi/ffiplatform.py ${PYSITELIB}/cffi/ffiplatform.pyc ${PYSITELIB}/cffi/ffiplatform.pyo ${PYSITELIB}/cffi/gen_src.py ${PYSITELIB}/cffi/gen_src.pyc ${PYSITELIB}/cffi/gen_src.pyo ${PYSITELIB}/cffi/lock.py ${PYSITELIB}/cffi/lock.pyc ${PYSITELIB}/cffi/lock.pyo ${PYSITELIB}/cffi/model.py ${PYSITELIB}/cffi/model.pyc ${PYSITELIB}/cffi/model.pyo ${PYSITELIB}/cffi/parse_c_type.h ${PYSITELIB}/cffi/pkgconfig.py ${PYSITELIB}/cffi/pkgconfig.pyc ${PYSITELIB}/cffi/pkgconfig.pyo ${PYSITELIB}/cffi/recompiler.py ${PYSITELIB}/cffi/recompiler.pyc ${PYSITELIB}/cffi/recompiler.pyo ${PYSITELIB}/cffi/setuptools_ext.py ${PYSITELIB}/cffi/setuptools_ext.pyc ${PYSITELIB}/cffi/setuptools_ext.pyo ${PYSITELIB}/cffi/vengine_cpy.py ${PYSITELIB}/cffi/vengine_cpy.pyc ${PYSITELIB}/cffi/vengine_cpy.pyo ${PYSITELIB}/cffi/vengine_gen.py ${PYSITELIB}/cffi/vengine_gen.pyc ${PYSITELIB}/cffi/vengine_gen.pyo ${PYSITELIB}/cffi/verifier.py ${PYSITELIB}/cffi/verifier.pyc ${PYSITELIB}/cffi/verifier.pyo @ 1.13 log @py-cffi: update to 2.0.0. Added support for free threaded CPython (3.14t+ only). (#178) Note that the free-threaded build does not yet support building extensions with the limited API, so you must set py_limited_api=False when building extensions for the free-threaded build. CPython 3.13t is not currently supported due to differences in sync primitive behavior from 3.14t that result in segfaults. Added support for Python 3.14. (#177) Dropped support for Python 3.8. @ text @d1 2 a2 2 @@comment $NetBSD$ ${PYSITELIB}/_cffi_backend.so a6 1 ${PYSITELIB}/${WHEEL_INFODIR}/licenses/AUTHORS d9 1 d14 3 d46 3 @ 1.12 log @Fix PLIST after py-setuptools update; bump depends and revision @ text @d1 2 a2 1 @@comment $NetBSD: PLIST,v 1.11 2023/11/05 13:44:36 wiz Exp $ d7 1 a9 1 ${PYSITELIB}/_cffi_backend.so @ 1.11 log @py-cffi: convert to wheel.mk Does not support Python 2 any longer. Bump PKGREVISION. @ text @d1 1 a1 3 @@comment $NetBSD$ ${PYSITELIB}/_cffi_backend.so ${PYSITELIB}/${WHEEL_INFODIR}/LICENSE d6 1 d8 1 @ 1.10 log @py-cffi: fix for Python 2 @ text @d1 1 a1 8 @@comment $NetBSD: PLIST,v 1.9 2023/10/04 21:51:44 adam Exp $ ${PYSITELIB}/${EGG_INFODIR}/PKG-INFO ${PYSITELIB}/${EGG_INFODIR}/SOURCES.txt ${PYSITELIB}/${EGG_INFODIR}/dependency_links.txt ${PYSITELIB}/${EGG_INFODIR}/entry_points.txt ${PYSITELIB}/${EGG_INFODIR}/not-zip-safe ${PYSITELIB}/${EGG_INFODIR}/requires.txt ${PYSITELIB}/${EGG_INFODIR}/top_level.txt d3 6 d19 2 a20 2 ${PLIST.py3x}${PYSITELIB}/cffi/_shimmed_dist_utils.pyc ${PLIST.py3x}${PYSITELIB}/cffi/_shimmed_dist_utils.pyo @ 1.9 log @py-cffi: updated to 1.16.0 v1.16.0 * Add support for Python 3.12. With the removal of ``distutils`` from Python 3.12, projects using CFFI features that depend on ``distutils`` at runtime must add a dependency on ``setuptools`` to function under Python 3.12+. CFFI does not declare a runtime ``setuptools`` requirement to avoid an unnecessary dependency for projects that do not require it. * Drop support for end-of-life Python versions (2.7, 3.6, 3.7). * Add support for PEP517 builds; ``setuptools`` is now a required build dependency. * Declare ``python_requires`` metadata for Python 3.8+. This allows unsupported Pythons to continue using previously released sdists and wheels. * Move project source under ``src/``; a more standard layout that also enables CI to more easily catch packaging errors. @ text @d1 1 a1 1 @@comment $NetBSD: PLIST,v 1.8 2019/02/16 23:37:23 adam Exp $ d20 2 a21 2 ${PYSITELIB}/cffi/_shimmed_dist_utils.pyc ${PYSITELIB}/cffi/_shimmed_dist_utils.pyo @ 1.8 log @py-cffi: updated to 1.12.1 v1.12.1 CPython 3 on Windows: we again no longer compile with Py_LIMITED_API by default because such modules still cannot be used with virtualenv. The problem is that it doesn’t work in CPython <= 3.4, and for technical reason we can’t enable this flag automatically based on the version of Python. Like before, Issue 350 mentions a workaround if you still want the Py_LIMITED_API flag and either you are not concerned about virtualenv or you are sure your module will not be used on CPython <= 3.4: pass define_macros=[("Py_LIMITED_API", None)] to the ffibuilder.set_source() call. v1.12 Direct support for pkg-config. ffi.from_buffer() takes a new optional first argument that gives the array type of the result. It also takes an optional keyword argument require_writable to refuse read-only Python buffers. ffi.new(), ffi.gc() or ffi.from_buffer() cdata objects can now be released at known times, either by using the with keyword or by calling the new ffi.release(). Windows, CPython 3.x: cffi modules are linked with python3.dll again. This makes them independant on the exact CPython version, like they are on other platforms. It requires virtualenv 16.0.0. Accept an expression like ffi.new("int[4]", p) if p is itself another cdata int[4]. CPython 2.x: ffi.dlopen() failed with non-ascii file names on Posix CPython: if a thread is started from C and then runs Python code (with callbacks or with the embedding solution), then previous versions of cffi would contain possible crashes and/or memory leaks. Hopefully, this has been fixed. Support for ffi.cdef(..., pack=N) where N is a power of two. Means to emulate #pragma pack(N) on MSVC. Also, the default on Windows is now pack=8, like on MSVC. This might make a difference in corner cases, although I can’t think of one in the context of CFFI. The old way ffi.cdef(..., packed=True) remains and is equivalent to pack=1 (saying e.g. that fields like int should be aligned to 1 byte instead of 4). @ text @d1 1 a1 1 @@comment $NetBSD: PLIST,v 1.7 2017/09/30 13:09:47 adam Exp $ d16 6 @ 1.7 log @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! @ text @d1 1 a1 1 @@comment $NetBSD: PLIST,v 1.6 2017/04/05 15:54:26 wiz Exp $ d44 3 @ 1.6 log @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, compares equal to 42 and compares equal to b'A'. Unlike C, 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. @ text @d1 1 a1 2 @@comment $NetBSD$ ${PYSITELIB}/_cffi_backend.so d9 1 d13 1 @ 1.5 log @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. 1.7.0 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) @ text @d30 3 @ 1.4 log @Update py-cffi to 1.5.0: v1.5.0 ====== * Support for `using CFFI for embedding`__. @ text @a32 3 ${PYSITELIB}/cffi/gc_weakref.py ${PYSITELIB}/cffi/gc_weakref.pyc ${PYSITELIB}/cffi/gc_weakref.pyo @ 1.3 log @Update to 1.0.3: 1.0.3 Same as 1.0.2, apart from doc and test fixes on some platforms. 1.0.2 Variadic C functions (ending in a ... argument) were not supported in the out-of-line ABI mode. This was a bug-there was even a (non-working) example doing exactly that! 1.0.1 ffi.set_source() crashed if passed a sources=[..] argument. Fixed by chrippa on pull request #60. Issue #193: if we use a struct between the first cdef() where it is declared and another cdef() where its fields are defined, then this definition was ignored. Enums were buggy if you used too many ... in their definition. 1.0.0 The main news item is out-of-line module generation: for ABI level, with ffi.dlopen() for API level, which used to be with ffi.verify(), now deprecated @ text @d2 1 a9 1 ${PYSITELIB}/_cffi_backend.so d14 1 @ 1.2 log @Update to 0.8.1, changes not found. @ text @a1 1 ${PYSITELIB}/_cffi_backend.so d5 1 d9 1 d13 1 d20 3 d41 7 @ 1.1 log @Import py27-cffi-0.7.2 as devel/py-cffi. 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. @ text @d30 3 @