On Wed, 6 Oct 2021 at 08:52, Jason Moore <moorepa...@gmail.com> wrote:
> I think we should relax our stringent no dependency stance for pure python > dependencies. Pure python dependency management is essentially solved now > for the python ecosystem with the various package managers. This dependency > would also be pulled into the sympy organization, so we will have just as > much control to maintain it as code in sympy's codebase. > I don't that there should be a no dependency stance. In fact I think that it was a mistake previously to not use dependencies like multipledispatch and pytest. Maintaining sympy is hard enough without needing to maintain out of date forks of otherwise independently maintained projects. > Francesco is a long time valued contributor and if he wants/needs matchpy > to help him make sympy better, then we should enable him to do that. > Putting up a wall here likely only creates frustration and demotivation. > There is likely more value in unleashing Francesco's matchpy improvements > to sympy than any devalue adding a dependency to sympy creates. > I did not say that I opposed the proposal just that there needs to be some justification for it in the SymPEP. The purpose of that document is to explain the rationale for changes so that a decision can be considered on its merits and also to communicate to others why a decision has been made. As it stands though the document does not address reasons for what is actually proposed which is to make matchpy a hard dependency. If there are good reasons for doing that then they should be written in the SymPEP. Partly those reasons might be speculative but they can still be listed. -- Oscar > Jason > moorepants.info > +01 530-601-9791 > > > On Wed, Oct 6, 2021 at 9:38 AM Francesco Bonazzi <franz.bona...@gmail.com> > wrote: > >> >> >> On Tuesday, October 5, 2021 at 2:07:06 p.m. UTC+2 Oscar wrote: >> >>> >>> I agree that pattern matching is a crucial part of a CAS and should >>> really be the core of SymPy. If I was redesigning SymPy from scratch then >>> everything would be built on top of a pattern-matching engine and almost >>> all of the logic from the myriad Basic subclasses would just be written as >>> pattern rules. My equivalent of SymEngine would just be a C implementation >>> of the pattern-matching engine rather than a repeat of the object-oriented >>> design of SymPy. >>> >> >> SymPy can still be modified in order to use a pattern matcher. >> >> Also, MatchPy has been partly translated into C++ inside the SymEngine >> project: >> >> https://github.com/symengine/symengine/tree/329a04be017daff0362b9177da2ef5b7e5d605f7/symengine/utilities/matchpycpp >> >> >>> >>> I also agree that matchpy looks like a good implementation of >>> pattern-matching and it makes sense for it to be usable with SymPy. What >>> the SymPEP does not address though is what benefit is gained for users by >>> making matchpy a non-optional dependency. The examples shown look like >>> somewhat specialised usage for which an interested user could just choose >>> to install matchpy. >>> >> >> The benefits are mostly for SymPy development. You can start defining >> replacement rules to implement new algorithms. >> >> >>> RUBI would be a good motivation but as far as I can tell RUBI does not >>> yet work. Actually I would prefer it if RUBI was already in a separate >>> package from SymPy - it should not have been merged until it was at least >>> partially working. The rubi_tests folder is included for all users and >>> includes e.g. the sympy/integrals/rubi/rubi_tests/tests/test_trinomials.py >>> file which wastes at least 1.5MB disk space for every single SymPy user for >>> precisely zero benefit (these tests should clearly be in a separate repo). >>> I don't see how making matchpy a non-optional dependency would make it any >>> easier to improve RUBI since anyone who wants to work on it can just >>> install matchpy. In fact if RUBI was not in the main SymPy repo then it >>> could have a hard dependency on matchpy. >>> >> >> This can be done. >> >> >>> The cost of making matchpy a non-optional dependency would be felt by >>> downstream distributors of SymPy who would then have an additional >>> dependency to include. It would also be felt by all users of SymPy with >>> longer install time, more disk space etc. If a user does not use any of >>> it's features then this cost comes with no benefit. >>> >> >> Consider that it's pretty common now for libraries to depend on other >> libraries. An alternative would be to copy the MatchPy project as a >> subfolder inside SymPy (as it has been done for the *multipledispatch* >> module). >> >> >>> I am not saying this to disagree with the proposal but that there needs >>> to be a clear rationale for making matchpy a hard dependency and the SymPEP >>> does not address this at all. The SymPEP should also clearly spell out what >>> the downsides of the proposal are. >>> >> >> The major downside is probably that MatchPy has not been extensively >> tested with SymPy. There is a risk factor in relying on a new library. >> >> -- >> 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 sympy+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%40googlegroups.com >> <https://groups.google.com/d/msgid/sympy/003f5fd9-8137-40eb-a8a6-ca2378a08ccan%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAP7f1AhfqzVwWoqbZosP_uXoM%2BJkw9z5LuvAtXKi0feb5zg8vQ%40mail.gmail.com > <https://groups.google.com/d/msgid/sympy/CAP7f1AhfqzVwWoqbZosP_uXoM%2BJkw9z5LuvAtXKi0feb5zg8vQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxS8Ebd5LGPbgZorPgih_O3wW7mLPXAC4F_7MV%3D%3D3k05Xg%40mail.gmail.com.
