I haven't been part of the discussion back then. But I am also weighted toward having a separate string classes because
1. Symbol is actually more heavier strings because assumptions are stored and checked against. 2. I also see that atomic String class is implemented in codegen.ast separately, so there were some other use cases. On Tuesday, May 26, 2020 at 5:34:43 PM UTC+9, mcpl snu wrote: > > Currently, many classes in SymPy include Symbol in args to provide the > names to their instances. An example for this is sympy.vector.CoordSys3D > class. > > Although this can be a clever way to do it, I think this is wierd - > perhaps it's an abuse of using Symbol. As far as I know, SymPy's Symbol > is a scalar whose operations, e.g. addition, integration, etc... are > defined. When we say *"This 3D system's name is 'C'"*, we don't expect > that this 'C' can be substituted, divided, or subject to any other > operation. Then why use Symbol to denote it in the first place? > > Not only this design is unnecessary, it actually raises error. Please > refer to this issue page <https://github.com/sympy/sympy/issues/19300> > for example > > Although there can be many ways to circumvent this issue, I think the most > simple way is to introduce String class, which wraps str and is a > subclass of Atom. > > If there is any reason to use Symbol for this purpose that I overlooked, > please leave a comment here. Thank you. > -- 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/0ebe7487-2be3-4286-a824-4001bbbc0b40%40googlegroups.com.
