[build-system]
requires = ["setuptools", "cython"]
[tool.setuptools]
ext-modules = [
{name = "example", sources = ["example.pyx"]} # You can also specify all the usual options like language or include_dirs
]
That's true but I still don't see that so much because the core libraries are not as mature and often they're just thin wrappers around the C/C++/Fortran API without examples. Just as an example, I'd count this SUNDAILS library as like that:
https://docs.rs/sundials/0.3.2/sundials/
Nothing wrong with that as a starting point of course, but it's easier just to compile it as a dependency and look at the core documentation if you're familiar with C++; you'll need to be reading the C++ examples anyway to write Rust code with it.
What I mean is that (at least in my experience) people are not so commonly writing serious numeric applications in Rust as Python extensions because the numeric libraries on which you'd typically write in a compiled language are not as well developed and are in themselves often thin wrappers over C/C++ code at the moment. When you write an extension library you typically want all the 'slow' stuff to be done in a layer below the interpreted language for performance reasons.
So if you wanted to write a Python Physics library that included, say, time integration with an implicit solver like those SUNDIALS provides (and SUNDIALS is like the gold standard in this area), you have less well used options for the time integration part if you write the extension in Rust as if you do in C/C++. Or you're using the same library anyway.
SymPy has Solvers for ODEs and PDEs and other libraries do convex optimization. SymPy also has lambdify to compile from a relatively slow symbolic expression tree to faster 'vectorized' functions
>>> """Convert a SymPy expression into a function that allows for fast numeric evaluation""" [with e.g. the CPython math module, mpmath, NumPy, SciPy, CuPy, JAX, TensorFlow, PyTorch (*), SymPy, numexpr, but not yet cmath]
I’m perfectly familiar with SymPy and it’s great but it doesn’t have methods comparable in performance in stiff PDEs to CVODE, and it’s not parallelised either. CVODES offers sensitivity analysis, ARKODE offers multi rate integrators for systems where the ODE can be decomposed into slow and fast rates, etc. etc. - it’s a much more sophisticated and specialist library.
If you add Arrow RecordBatch or Table output to CVODE with arrow-cpp, e.g. Dask can zero-copy buffers to Python (pyarrow, pandas.DataFrame(dtype_backend=arrow), or narwhals) when it needs to gather / fan in at a computational barrier in a process-parallel workflow.
Is sklearn-deap useful with scikits.odes and sundials (and dask or not)?
Persons who need pyproject.toml functionality could consider contributing tests so that the free functionality might be considered adequate for their purposes.
From "Building cython extensions using only pyproject.toml (no setup.py)" https://github.com/pypa/setuptools/discussions/4154#discussi... :