-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SymPy Deprecation backlog #22892
Comments
My guess would be that no one gets back to it until it actually bothers someone. I've mentioned this elsewhere before, but the duration that something is in the deprecated state should be tied to real time, so like 1 year not 2 minor version bumps. I don't think PRs that remove deprecated features that are >1 year in that state will meet any resistance :) Some are a bit tricky to remove though. |
It's not hard to remove these things. The purpose of deprecation is twofold:
Sometimes though there isn't any urgent need to remove something after it is deprecated. The deprecation warning ensures that it isn't used within SymPy and therefore isn't a hindrance to improvements elsewhere in the codebase. Direct downstream use may or may not break over time but usually there is some test that the deprecated functionality continues to work in a basic way (while issuing a warning). From a practical perspective this might mean that the original problem is effectively solved and hopefully that downstream code didn't break but might now see a warning. The removal of things that are deprecated happens later just because either a need arises or someone decides to clean up the code. At least within sympy that "cleanup" is treated like many other possible cleanups that could be done at any time once someone has the time and inclination to do it. A priori I don't see any reason why deprecated things should be removed quickly. Probably the reverse is true: it's kindest to downstream to leave the deprecation warning there for as long as possible so if there is no cost then why not just leave it? |
I would love to clean up our deprecation policy https://github.com/sympy/sympy/wiki/Deprecating-policy. Ideally it should be a SymPEP (https://github.com/sympy/sympeps), but those are still something that we haven't fleshed out fully yet sympy/SymPEPs#2. I would also like to
I think the general stuff on that page about what and why things should be deprecated is solid, but if there's anything about it you don't like, we should improve it as well. This has been discussed in #20015.
It's worth noting that we can also use normal (non-deprecation) warnings. That's more appropriate if there isn't always replacement functionality, or if it's something we might not actually remove (an example of this might be validation of assumptions passed into Symbol #21417). There are also ways that we can disallow things in library code without deprecating them for users, for instance, by analyzing the call stack to see if the caller is user code or library code, or by having a "hidden" warning that is only turned on in the SymPy test suite. For example, we could use one of these techniques to disallow string inputs in library code today #11003, without worrying about deprecating it for user code. |
Another thing I mentioned in that issue that I like is that we should write much longer descriptions in the warning messages themselves. Ideally the message should be enough for most users to know how to fix their code, without having to go to the documentation link. The documentation can be more about the "why" a deprecation was done, as well as giving longer examples. |
I have independently of this (didn't find it until now) removed most of the 1.3 and earlier deprecations in #22949 and #22952 There are three additional deprecations in |
And, yes, it is not always that straightforward to remove them, at least not without understanding the code (which is the reason I did not remove all of them). |
Since #22900 is now merged, eventhough this issue isn't solved entirely, at least it is currently being managed, so I am closing this issue. |
There is a bunch of code that has been deprecated for a long time. Maybe it is a good idea to set a "hard cut-off" for deprecated code e.g. "everything deprecated in version 1.5 or earlier gets removed"?
Or is it prefered to keep it in the codebase until it is actively interfering with development?
Or is the reason it is not removed because it is difficult to actually remove these pieces of code?
The text was updated successfully, but these errors were encountered: