Le samedi 21 juillet 2012 à 19:54 -0600, Aaron Meurer a écrit : > 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.
No, Symbol is definitely not the sympy version of str. It has none of the methods expected of a string and does a whole lot of things completely unrelated to strings. If Symbols didn't have names, very little would change, outside of printing. The fact that Symbols (and functions, and classes, etc.) have a name doesn't make them strings. On the contrary, it shows that they are nothing like strings, because strings are text but don't have an additional textual label (aka a name) attached to them. > One possible issue is that Symbol has assumptions tied into it. > Hopefully the new assumptions will make this less of an issue. We Assumptions are part of the identity of a Symbol, so the new assumptions won't change that. > 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. Having a base class for named objects would be good, but it can only work for atoms, as non-atoms can't have strings in their args. > > 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.
