# D4.1: Python/Cython bindings for PARI and its integration in Sage
Luca De Feo
# A matter of language
- Low level language.
- Fast, portable.
- Slow development.
- High level language.
- Good for fast prototyping, even more portable.
- Slower performance.
- Popular among the scientific community.
**Best of both worlds:** write in Python, call fast C libraries.
# A matter of systems
- One of the oldest Mathematics software (1983): algebra, number theory.
- Well known and used in the computational number theory community
(e.g., LMFDB, see WP6).
- Written in C.
- General purpose Mathematics software.
- Python interface (API) to many software and libraries (including
- Additional functionality written in Python: e.g. cryptography,
- Three dimensional hyperbolic geometry.
- Uses PARI/GP.
- Written in Python (Marc Culler and Nathan Dunfield).
M = Manifold('9_42') # getting one manifold from the database
M.browse() # open a widget with all info
## The CyPari fork
- In 2012 Marc Culler *forks* the SageMath interface to PARI/GP:
- Makes SnapPy independent of SageMath.
- Allows SnapPy to run seamlessly on Windows.
- The project is called CyPari.
- While CyPari freezes and lags behind, the SageMath interface gets
- Updates to the PARI/GP library.
- Automatized interface generation (J. Demeyer).
## Our goal
Work on a **clearly identified** piece of software, **useful to two
communities**, is dispersed among different projects.
- Extract the SageMath PARI/GP interface as an independent package.
- Build SnapPy on top of it.
- Maintain it inside the community, make it available to more
Work split in 3 phases (33% done):
- Extract Sage signalling API (package cysignals, done)
- Already used in other projects: <https://github.com/malb/fpylll>
- Decouple SageMath's PARI/GP interface from the *coercion model*.
- Clean up the interface API, by removing unneeded object orientation
and external dependencies.
Easy last step: move SageMath's PARI/GP interface to a separate Python
package, depending on cysignals.
## Problems encountered
- SageMath interface more entangled with internals than initially
- Only recently we found a suitable design.
- Windows compatibility harder than initially thought for cysignals.
We estimate the remaining work to three person/weeks. We will be able
to deliver by M12.
## Lessons learned, perspectives
- General consensus on moving interfaces out of SageMath's codebase:
- Benefits the community.
- Makes design clearer.
- Makes it easier to package for distributions (see WP3).
- Cysignals can be reused to externalize many other SageMath
- This case study (arguably one of the hardest) will show how
sustainable it is to extract and maintain these interfaces.
- Work to be continued in deliverable 4.2.