Am Mittwoch, 26. Dezember 2018 01:25:59 UTC+1 schrieb Simon King: > > Hi Timo. > > On 2018-12-25, Timo Kaufmann <eisf...@gmail.com <javascript:>> wrote: > > I don't really see a reason to rename it. The old name doesn't suggest > that > > it is implemented with pexpect. > > No, it does, by tradiation: > AFAIK, *ALL* interfaces that are named after a third-party computer > algebra > projects (gap, singular, r, pari, polymake, maxima, and of course magma, > mathematica...) used to be pexpect interfaces. There has been > an increased use of C level interfaces (libsingular, libgap, ...), but I > got > the impression that their names give a hint that they are not pexpect > interfaces. >
You're involved with the project. I doubt most users ever had a look at the implementation. > For me, suddenly changing the gap or singular interface from pexpect to C > would > be a nasty surprise that would totally break my research code, because... > > > The implementation by definition should be n implementation detail, > > the behaviour is largely the same. > > ... indeed this is (from my perspective) a weakness of libgap: > libgap.__call__ > is not equivalent to gap.__call__ and libgap.eval isn't equivalent to > gap.eval. > Also the way we currently use libsingular is totally not the same as > calling the singular pexpect interface. > > I don't know if the C interface to R behaves exactly like the pexpect > interface. If they behave truely (not just *largely*!) the same, then of > course a change from pexpect to C interface shouldn't matter very much. > rpy2 also runs an R interpreter that behaves just as a REPL would, it just communicates at an API level instead of parsing text. It behaves the same (except were the old interface didn't work at all). The only edge case I'm aware of has to do with help pages and that is fixed. > However, still I would be in favour of a deprecation: There should, for > the reasons stated in other posts, be only a single instance of the C > interface, called "r", replacing the current pexpect interface called > "r" (provided that they behave the same). But for the time being, there > should still be sage.interfaces.r.R so that R() results in a deprecation > warning and returns a new instance of the R pexpect interface. > I still don't think there is a good reason to revive the pexpect interface. Removing/deprecating `R()` sounds reasonable. > Note that there may also be issues with pickling. Has it been possible > to pickle objects defined via the pexpect R interface? If this is so, > would the stored pickles automatically unpickle as C interface R > objects? > No, that was also one of the things broken with the old interface: https://trac.sagemath.org/ticket/26596#comment:38 Also the internal sage objects are still the same (`RElement` etc). I suggest that you play with it / read the ticket and see if there are actually relevant differences. Regards, Timo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
