Question on using Symbol as instance naming

[mcpl snu]

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.

[Aaron Meurer]

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

> --
> 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+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/1ce4ea17-af3e-4fc4-9870-013b4444f57a%40googlegroups.com.

[mcpl snu]

Can you recall why it was rejected, please? I really would like to know.

2020년 5월 27일 수요일 오전 4시 51분 16초 UTC+9, Aaron Meurer 님의 말:

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 <mcpl...@gmail.com> 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 sy...@googlegroups.com.

[S.Y. Lee]

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.

[Aaron Meurer]

One of the arguments I recall is that a String object would have lots
of string related methods. But string manipulation isn't really
something that SymPy as a symbolic system needs to support.

The codegen use-case was not imagined back then. I don't think the
codegen classes should be used outside of codegen. They are designed
to represent abstract programming language concepts for generating
code.

Aaron Meurer

> --
> 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+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/0ebe7487-2be3-4286-a824-4001bbbc0b40%40googlegroups.com.

[S.Y. Lee]

In my opinion, the argument that string manipulation is out of scope, also applies for all the container classes like Dict and Tuple.

And for now, I don't think that sympy is excessively using arithmetics of those objects internally because of slowdowns.

> To unsubscribe from this group and stop receiving emails from it, send an email to sy...@googlegroups.com.

[S.Y. Lee]

So if those Tuple and Dict stay, I don't think that it gives a sufficient reason that string is any exception than that.

[mcpl snu]

I agree with SYLee. All we need is just a wrapper of str. I doubt that anyone will need to manipulate with that.

SymPy doesn't need to support string manipulation indeed: That's why we don't have to implement those methods.