It might be useful to list the points of friction that you are aware of in the design of python with respect to use in sympy, to see if people have work-arounds that you might have missed, or to encourage people to point out solutions that exist in alternative languages that already exist.
As long as you are considering other programming languages, maybe you should look at Lisp, which is used in a number of well-known symbolic math systems, and is in some respects python-friendly. RJF On Sunday, January 14, 2018 at 5:26:14 PM UTC-8, Henri Tuhola wrote: > > Hello, > > I would directly want to reach people who have been developing sympy, so I > posted on your mailing list. > > Development of sympy on top of python has not been frictionless, and I > think you know that. Unfortunately only few people know what's even wrong > there. > > I am working on a new programming language and found out that the choice > of how to allow extension of arithmetic is a really tough problem to figure > out. Simply implementing arbitrary operator overloading and calling it a > day doesn't seem to be so good choice. > > I wonder that if you had a choice of redesigning arithmetic in Python to > better support sympy, what would you attempt to solve? If you know what you > would do, I would gladly read that. > > Thank you ahead of the time. -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b623867f-6d3e-4d06-84f2-2938a9fb3622%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
