> On 8/02/2020, at 1:20 AM, Simon King wrote:
>
> On 2020-02-07, Han Frederic wrote:
>> It is indeed rare for an spkg to be linked to the sage library...
>
> ... but it is not the only one. p_group_cohomology is similar in that
> regard.
Being a downstream package that way is absolutely fin
Hi Frederic,
On 2020-02-07, Han Frederic wrote:
> It is indeed rare for an spkg to be linked to the sage library...
... but it is not the only one. p_group_cohomology is similar in that
regard.
> We need one of the following
> (to not lose any features) either giacpy_sage is an external package
I am in favor of moving giacpy_sage inside sage/libs. But it does
not really fits Sage code standard. It is mostly undocumented
and untested.
This does not look so bad as most of the code is
"""
cdef class Pygen:
def functionXYZ(self, *args):
return GiacMethods['functionXYZ'](self,
The cypari2 related files in sage/libs/pari/ are rather minimal
$ wc -l sage/libs/pari/*
4 pari/all.py
13 pari/convert_flint.pxd
158 pari/convert_flint.pyx
13 pari/convert_gmp.pxd
209 pari/convert_gmp.pyx
3 pari/convert_sage.pxd
296 pari/convert_sage.pyx
217 pari/__init__.py
I’ll claim responsibility for the name change request!
More seriously, after reading this and thinking a little bit I would
really prefer if it was merged in sage/libs. The alternative means that
we have a true circular dependency sage <-> giacpy_sage and things
will start to get wild as soon as
First, thank you for this discussion.
About the sage pip install project. The problem is that I don't know at all
what will be available.
But if you are done with sage's pyx files in src/sage/libs then it should
be similar with giacpy_sage.
It is indeed rare for an spkg to be linked to the sa
