Data classes are a nice syntactic convenience, and it's useful to have them if you are using something like that so you don't have to rewrite all the boilerplate. But I've never really found the "objects representing a tree of expressions" as being the hard part of symbolic computation. A competent Python programmer could easily rewrite all the logic of dataclass (or the most basic logic of Basic) from scratch in an hour.
The only real challenges are 1) making things as syntactically nice as possible. I think SymPy does pretty well here, although there are places where things could be improved. And 2) the overall performance. >From what I've heard, dataclasses aren't particularly performant, so I don't think they specifically are a good choice in that regard. Aaron Meurer On Tue, Dec 13, 2022 at 1:22 AM S.Y. Lee <[email protected]> wrote: > > After Python 3.6 dataclasses were introduced. > > Usually, the basic objects of symbolic computation (term) is based on > syntactic equality between the objects, which has isomorphism or homomorphism > (if there is eager evaluation) from term algebra, which dataclass can easily > implement. > > For example, dataclass(frozen=True) can easily give immutable objects, built > in syntactic equality, and also the substitution operation between terms to > terms, and also default printing capability, such that it is less black boxed > version of python object. > > It is easy to implement a symbolic computation library with dataclasses, > without a need to implement everything from scratch, so it can be a > consideration for future in SymPy library to refactor or if we can encourage > people to implement new symbolic objects in this paradigm, than sticking to > the old architecture. > > There are alternatives like typing.NamedTuple or typing.TypedDict. And there > is controversy between which has less overhead. However, I assume that they > are feasible solution if you need untyped calculus. (There are sometimes > cases where untyped calculus is more natural model for the problem, like if > we have to dynamically create huge numbers of classes with different names) > > -- > 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/d9caad27-fb02-434a-b260-5ab80df91f9an%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%3D6Li76_4nuEWhRtSpbk%2B4KMpV9g_D%3D4JU-h-Linv5DSqfw%40mail.gmail.com.
