A lower-level interface to Flint

[oscarbenjamin]

Currently the python-flint interface to Flint is sort of somewhere between a high-level interface and a lower-level interface. In #53 I mention some ideas related to fleshing out what a more complete higher-level interface might look like. It will take a long time though to design high-level interfaces to all parts of Flint though and those interfaces will always lag behind the features that exist in Flint itself.

Another idea would be to try to add a lower-level interface within python-flint that just directly wraps each individual C type and public C function. There could be Cython types for e.g. ulong, slong, fmpz_t etc and then Cython functions like fmpz_add that take these types. The code to use this sort of low-level interface would look exactly like the corresponding C code using Flint's C API with the possible exception that Python's reference counting could be used instead of needing explicit *_free calls.

The advantages of having a low-level interface like this are that:

• The Cython code could be generated in a semi-automatic way e.g. by scraping the function names from the Flint headers so that it always keeps up with the latest new functions in Flint.
• While the low-level interface might not be very convenient it would always be possible to call any Flint function from Python.
• It might be easier for python-flint contributors to prototype some new additions to python-flint in Python before subsequently transferring them to Cython.

[fredrik-johansson]

The Cython code could be generated in a semi-automatic way e.g. by scraping the function names from the Flint headers so that it always keeps up with the latest new functions in Flint.

Some others (eg Arblib.jl) have done this by scraping the documentation rather than the header files.

[Mollywall]

Thanks for the info. Tell Tims Survey