Now I understand a bit better what you mean. I can imagine making all of SymPy work like this (but I do not like it). For instance, `Expr.subs` (which is among the most important methods used in conjunction with `solve()`) works more or less like that.
However there are a few issues with this approach and I still think that simply making the output more consistent is a better idea: - Consistency is more aesthetically pleasing (this is not a very serious argument, I know :). - Making the output more consistent and not having all sympy functions check the type of the output is much simpler (in LoC metric, for instance). - What I propose is almost done already (the new flag that Chris Smith added to `solve` in PR 1324 did not involve any invasive changes). On the other hand checking that all sympy functions work with any type of output from the solvers is more involved. - If we want sympy to treat both types of output in the same way, we also force any downstream projects to check for the type of output. - There are solvers that returns stuff that is not directly usable by other functions. The ode solver returns Eq instance or a list of Eq instances. You always need to do some checks or transforms on that output. It would be easier to just have `for sol in solutions` instead of `if iterable(solutions): this; else: that` Basically I feel (not a technical argument) that your way focuses on a minor (in my opinion) improvement to exploratory work, that is to some detriment to the rest of the library (mainly in terms of simplicity). -- 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.
