Well, there are some advantages to having your objects in a Tuple. The methods/properties .has, .subs, .match, .free_symbols, .args, .find, .replace, .is_Anything, and many others all work on it, because it's Basic.
Aaron Meurer On Sat, Aug 13, 2011 at 12:59 AM, Chris Smith <[email protected]> wrote: > On Sat, Aug 13, 2011 at 12:11 PM, Aaron Meurer <[email protected]> wrote: >> This is kind of an obscure argument. We need to decide what the API >> should be so that it's consistant and useful. > > :-) So let's stop talking about it. We have a consistent and useful > API. Let's not change it unless we can show an advantage to sending > back containers other than python's standard ones. Other than the > lamish suggestion I made, I like keeping in mind that I'm in python > and sympy is not about containers, it's about mathematical objects. So > operations that return an iterable of some sort shouldn't make it a > sympy iterable unless there is a compelling reason to do so. There is > nothing inherently mathematical about a Tuple object over a tuple > object, so I say, let's not start tying Gordian knots. > > I can be persuaded if there is a compelling advantage to having Tuples > as output instead of tuples. (But I actually think this is a > discussion that can wait until v 1.0...we have a lot more pressing > things than to start worrying about this, don't you think?) > > -- > 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.
