>From the page: "also, Sage attaches _sage_ methods to various SymPy classes, which provide the opposite conversion."
SymPy also has various _sage_ methods, but mainly only in the core. Should we keep these in SymPy? It sounds like you are already adding a bunch of your own, so maybe we should just move them all to the sage codebase. We could also move them all to the SymPy codebase too, if that sounds more preferable. I would assume having them in Sage is better because that puts it closer to the Sage developers who understand that code, and also the Sage CI that tests against the latest development version of Sage. Aaron Meurer On Tue, Aug 24, 2021 at 5:48 PM Matthias Köppe <[email protected]> wrote: > > Some here on the list may be interested in SageMath's extended sympy > interface merged in the just-released Sage version 9.4. > > In particular, all mathematical sets and algebraic structures ("Parents") of > SageMath are now accessible to SymPy by way of a wrapper class SageSet, which > implements the SymPy Set API. > > More detail: https://wiki.sagemath.org/ReleaseTours/sage-9.4#Symbolics > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/da0fcd9c-0990-4e0d-a378-faee02e97673n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6J%2BKKotM0BEANP661RPsBg_qTmDMzVZ_mc-DjBwtr5V0A%40mail.gmail.com.
