<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>I'd like to clarify what exactly we mean by exposing a C API.  Do we have in mind that our random number generators can be used from standalone C code, or via Cython `cimport` like with the current numpy.pxd?<br></div><div><br></div><div>It sounds like we want to expose the highest level generators; do we also want to provide access to the bit streams?<br></div><div><br></div></div></blockquote><div><br></div><div>What do you mean by standalone C?  A Python extension is written in C (but not Cython)?  Or a C application that doesn't include Python.h?  The former is pretty easy since you can use a few PyObjects to simplify initializing the bit generator, and the rest of the code can be directly used in C without any more Python objects.  The latter is also doable although the low-level functions needed to initialize the bit generators (which are just C structs) have no standardization.  I think the only component in a standalone C application that would need some non-trivial work is SeedSequence (i.e., more than changing function names or reorganizing files).</div><div><br></div><div>Like Robert, I suspect that Cython users would be the largest immediate beneficiaries of a lower-level API.</div><div><br></div><div>numba end-users can already consume the bit generators through the exposed CFFI/ctypes interface they provide.  These can then be used with the higher-leverl generators, although end users have to build a shared lib/DLL first. Getting the C API in shape to be used directly by numba is probably a bigger task. </div><div><br></div><div>Kevin</div><div><br></div><div><br></div><div><br></div></div></div>