I suggest to start the unit tests of MatchPy in debug mode and follow the tree traversal to get some more insight. Indeed, the code is quite complicated, but the debugger may help. MatchPy also provides a tool to dump the state into a GraphViz dot file.
The idea is that matchpy_connector should not use all those ".register( )" methods, it should not have objects subclassing MatchPy objects (currently there is Wildcard). On Saturday, March 16, 2024 at 1:52:55 p.m. UTC+1 [email protected] wrote: > Hi, > Still I am in the process of understanding the matchpy code base. > at the moment I understand that, > > - Isinstance logic should replace to overridable method or any > preferred way ( wrappers around classes new classes also possible without > changing the existing code). > - __iter__ logic should change due to the tree traversal must change > accordingly, because it is rely on the inheritance. > - replace method in the matchpy connector should change because it is > replication of same code twice. > - Enhance the capability of matchpy_connector, because still does not > have the capability of solving calculus, matrices and more advanced > problems. > > what are the other things that might affect if we add overridable method > to Expressions? any suggestions for me to refer. > On Wednesday, March 13, 2024 at 2:04:20 PM UTC+5:30 Francesco Bonazzi > wrote: > >> On Wednesday, March 13, 2024 at 8:13:27 a.m. UTC+1 Aaron Meurer wrote: >> >> As far as we can tell, SymPy is the only thing that uses MatchPy, >> outside of the specific research software from that research group >> that it was developed for. >> >> >> Indeed, MatchPy is probably very underappreciated. Its developers haven't >> really advertised it enough. >> >> >> If making MatchPy more SymPy specific eases >> the development burden, we should do that, especially if we are going >> to fork it anyway. I think the core of it does need to remain >> independent of SymPy's types, especially if we want to try to write a >> Rust backend. >> >> >> I would still make an attempt at keeping it generic. The main issue is >> removing all "isinstance( ... )" and "__iter__" statements in the >> expression tree traversal algorithms of MatchPy and replace them with more >> generalizable statements. I'm confident this can be done and that we can >> still keep MatchPy generalizable to other libraries. >> > -- 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/9aed9d1b-4adb-418c-8fee-5742608693bcn%40googlegroups.com.
