I think this was discussed in the past and we decided we don't want a String object. Unfortunately GitHub's issue search is kind of bad so I'm having a hard time finding the discussions.
Aaron Meurer On Tue, May 26, 2020 at 2:34 AM mcpl snu <[email protected]> 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 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/1ce4ea17-af3e-4fc4-9870-013b4444f57a%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%3D6KTyJ8JeqJMKaF6TMrQYycXFosJo9vit-ZqLVfjxwNa2A%40mail.gmail.com.
