Wrap Python functions in a PARI t_CLOSURE

[jdemeyer]

To improve support for PARI functions taking closures, it would be very nice if we could wrap an arbitrary Python function in a t_CLOSURE.

This can be done using the PARI library functions install() and snm_closure().

[jdemeyer]

New commits:

​1cd2a3d

Wrap Python functions in PARI closures

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​3fe2918

Wrap Python functions in PARI closures

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​54a322a

Improve documentation

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​9089808

Merge tag '6.7.beta4' into t/18052/wrap_python_functions_in_a_pari_entree_and_t_closure

[pbruin]

I tried to implement a variadic version of this, and ran into #18623.

[pbruin]

Two comments on the current implementation:

• I think it is better to use ulong instead of unsigned long, because unsigned long may be smaller than the size of a pointer (on 64-bit Windows maybe?).
• The case where the Python function returns None is not handled correctly; I propose

  --- a/src/sage/libs/pari/closure.pyx
  +++ b/src/sage/libs/pari/closure.pyx
  @@@ -65,7 +65,10 @@ cdef inline GEN call_python_func_impl "call_python_func"(GEN* args, object py_fu
       # Call the Python function
       r = PyObject_Call(py_func, t, <dict>NULL)
  
  -    # Convert the result to a gen and copy it to the PARI stack
  +    # Convert the result to a GEN and copy it to the PARI stack,
  +    # treating None specially
  +    if r is None:
  +        return gnil
       return gcopy(objtogen(r).g)
  
   # We rename this function to be able to call it with a different
  

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​8bd8218	Merge remote-tracking branch 'origin/develop' into t/18052/wrap_python_functions_in_a_pari_entree_and_t_closure
​c14da15	Allow functions returning None

[pbruin]

This looks good to me now. We can always implement a variadic version later, but I think is not a priority at the moment. Also, the most naïve version of this makes the "cube" doctest fail, because even PARI doesn't support variadic functions in apply:

gp> g(v[..]) = v[1]^3
%1 = (v[..])->v[1]^3
gp> g(2)
%2 = 8
gp> apply(g, [1,2,3])
  ***   at top-level: apply(g,[1,2,3])
  ***                 ^----------------
  *** apply: incorrect type in apply (t_CLOSURE).

(The error only arises because the closure is variadic; non-variadic closures do work.)