I don't know if it is the best way, but in some sense, this does make sense. Symbol is the SymPy version of str, just as Integer is the SymPy version of int and Tuple is the SymPy version of tuple. If you want to have an integer or tuple contained in your object, you just use Integer or Tuple. So I think logically using Symbol for str makes sense.
One possible issue is that Symbol has assumptions tied into it. Hopefully the new assumptions will make this less of an issue. We could also expand the class structure so that there is a base class to Symbol that is only a string encapsulation, and subclasses for Symbol, and other things like BooleanSymbol. By the way, using Symbol instead of just a str will give you many useful things for free, like smart printing, easy replacement with .subs, the ability to drop in a Dummy if you need a dummy name, etc. Aaron Meurer On Sat, Jul 21, 2012 at 3:03 PM, [email protected] <[email protected]> wrote: > Or the other obvious solution is to make it official that objects that > want a name subclass (or contain in their args) an instance of Symbol. > > It is much easier as a solution (however rather hackish). > > I am just asking the community about what should the "canonical" way > to do it be. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
