110
edits
(→Symbolic package: More realistic project) |
(→Symbolic package: tweaks and formatting) |
||
Line 92: | Line 92: | ||
This project proposes to take this work further while also improving the long-term viability of the Symbolic package. Some goals include: | This project proposes to take this work further while also improving the long-term viability of the Symbolic package. Some goals include: | ||
* the possibility of using Pythonic directly rather than as one possible communication layer. For example, we might make "@sym" a subclass of "@pyobject". We also could stop using the "pycall_sympy__" interface and use Pythonic directly from methods. Note: there are open questions about how to do this during a transition time when we still support other IPC mechanisms. | |||
* exposing more functionality of SymPy with ''less glue'' in between. For example, we could allow OO-style method calls such as <code>f.diff(x)</code> as well as <code>diff(f, x)</code>. | |||
* Improvements to the Pythonic package and its long-term maintenance. | |||
* fixing up Symbolic to work with the latest releases of SymPy and Octave. The project has lagged for a few years and needs some efforts to port to recent and upcoming changes in SymPy code. | |||
* making Symbolic easier to maintain. The project currently has a low ''bus factor'': improving the CI, making regular releases easier, improving other aspects of maintenance and making the project more welcoming to newcomers. | |||
Working on this project involves and interesting and challenging mix of m-file code, Python code, and in the case of Pythonic, perhaps some lower-level C code. | Working on this project involves and interesting and challenging mix of m-file code, Python code, and in the case of Pythonic, perhaps some lower-level C code. |
edits