However, in the future, we may need have a complete review guideline even for setting up the parameter names, or to check if the bad naming choices are not marked as positional-only arguments. Although I believe that there are a lot of immature sympy commits before, but this is quite difficult to change the old code for this, so I'd leave them alone. On Saturday, February 19, 2022 at 5:54:08 AM UTC+2 asme...@gmail.com wrote:
> On Fri, Feb 18, 2022 at 7:39 PM Chris Smith <smi...@gmail.com> wrote: > >> 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. > > > The names are different from the order. The name of a positional argument > doesn't matter but the order obviously does. > > 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. > > > It depends on the specific keyword argument. In some cases it's not really > something you should ever use without using the keyword name. > > It would be good to be more explicit about this by using keyword-only > arguments. If you write > > def f(a, b, *, c=1, d=2): > ... > > Then f(1, 2, 3, 4) is not allowed. You have to write f(1, 2, a=3, b=4). > You can also do a similar thing with / to make things positional only > starting in Python 3.8. Keyword only OTOH has been available ever since we > dropped Python 2. > > I think we should use keyword only arguments a lot more, because it makes > the signature future proof against adding more keyword arguments. Making > more things positional only could be good too, although I rarely see people > unnecessarily calling a positional argument as a keyword argument. > > I started to do this in https://github.com/sympy/sympy/pull/21803 but > some felt that changing existing signatures was itself a compatibility > break (I disagree, but even if we decide this, it should be possible to > make the change with a custom decorator that just deprecates the old way). > Either way it's a huge undertaking to fix all the signatures in SymPy, but > worth it IMO. > > Aaron Meurer > >> >> /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+un...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/bc9ff2d6-540f-4942-9e9c-e79774d20088n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sympy/bc9ff2d6-540f-4942-9e9c-e79774d20088n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/ed985544-d60d-4af2-b52d-0313ceaa076en%40googlegroups.com.
