I think changing this will break tons of code in the wild. Isnt it best make a new "solve_new" and then leave solve be (maybe with a deprecation warning. You could call it `solve_equations` or something.
Jason moorepants.info +01 530-601-9791 On Thu, Mar 3, 2022 at 11:45 PM Oscar Benjamin <[email protected]> wrote: > On Thu, 3 Mar 2022 at 20:28, Aaron Meurer <[email protected]> wrote: > > On Thu, Mar 3, 2022 at 8:28 AM Chris Smith <[email protected]> wrote: > > > > > > Although the dict=True or set=True will give a standard output, can we > at least unify the case for when variables are given so we always get a > list of one or more dictionaries? So the above would be `[{x: -sqrt(y)}, > {x: sqrt(y)}]` and `[{x: y}]`, respectively. This would then make `solve` > always give a list of a) values for a univariate expression, b) a list of > one or more dictionaries for every other case. (Case (a) will give a list > of dictionaries if `dict=True`.) > > > > Changing the output type could break code that solves a specific > > equation. I am doubtful whether any users actually understand the > > output type behavior of solve without the dict=True flag. So > > personally I think we should clean it up. We already recommend using > > dict=True to get consistent output types, and this would only affect > > users who aren't doing that. > > It would be much better if solve always worked like that but obviously > that's not a backwards compatible change and I'm not sure what would > break. I don't think that the type of the output should depend on the > number of solutions although it could depend on the type of the > arguments (e.g a single equation vs a list of equations). At the > moment the type of the output can depend on the equations themselves > which is wildly awkward: > > In [3]: solve([x-1], [x]) > Out[3]: {x: 1} > > In [4]: solve([x**2-1], [x]) > Out[4]: [(-1,), (1,)] > > The ideal output for solve is absolutely a list of dicts though and it > would be good to make that the default at least when given a list of > equations. I guarantee that a lot of notebooks or other little bits of > code will depend on each of these random special cases though. > > -- > Oscar > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxROqs0CpGmSX2%3Dk8xJgTos9FPpP1x0GYP0aHCdiYErDnA%40mail.gmail.com > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAP7f1AhaE9Z1H9GUo1M2Ag5yb0v28uG-wUGRGA%3DuC2TTR%2BycNA%40mail.gmail.com.
