A concern I have about the policy is that "positional argument names are not Public API". I hope this is not correct, because if a function `f(a, b)` is changed to `f(b, a)` this would start failing without warning. I'm not even sure that `f(a, b, c=1, d=2)` should be allowed to be changed to swap the order of `c` and `d` since the API allows all 4 to be given and does not require the defaults to be given. So if `f(1, 2, 3, 4)` started returning (silently) the result for `f(1, 2, 4, 3)`, that would be a problem.
/c On Wednesday, January 26, 2022 at 3:38:55 PM UTC-6 Aaron Meurer wrote: > We are currently in the process of revamping our deprecations policy > at https://github.com/sympy/sympy/pull/22900, and we would like any > feedback from the community, both users and developers. Our current > policy that this would replace is on the wiki > https://github.com/sympy/sympy/wiki/Deprecating-policy. > > In particular, the new policy would have > > 1. An official period of at least 1 year for all deprecations to last. > Previously there was no official period for deprecations, and > deprecated functionality was removed more or less whenever we felt > like it. > > 2. Deprecations will still raise a SymPyDeprecationWarning, but the > proposed policy is to make the warnings contain much more verbose and > helpful messages. In addition, all warnings will be documented in the > respective docstrings, listed in a separate "all active deprecations" > document in the docs, and listed in the release notes for each release > (currently only the last of these is done). > > 3. The current silly "deprecation removal issue" thing that we (tried) > to do will be removed. All documentation for deprecations will be in > the documentation. > > 4. I have added some text to the document going over when backwards > compatibility breaks should be made (tl;dr: sparingly), and what does > and doesn't require deprecation to change. The document also has > developer instructions on how to add a deprecation to the code. > > One question we have for users is if you are happy with our current > SymPyDeprecationWarnings, which are relatively loud by default (they > use a warnings filter that always turns them on). Would you prefer > more silent warnings, like warnings that are documented but aren't > accompanied by a warning printed to the screen? > > Aaron Meurer > -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/bc9ff2d6-540f-4942-9e9c-e79774d20088n%40googlegroups.com.
