On Tue, Jul 16, 2019 at 6:46 PM Jeroen Demeyer <j.deme...@ugent.be> wrote: > > I have seen multiple discussions where somebody wants to deprecate a > useless function but somebody else complains that we cannot do that > because the function in question cannot be removed (because of backwards > compatibility). See https://bugs.python.org/issue29548 for an example. >
FWIW, we didn't have deprecated macro in 2017. Now we have it and I'm +1 to deprecate it. Especially, I want to force Py_SSIZE_T_CLEAN support (remove int support for #) in early 2020s (3.10, or 3.11). But PyEval_CallFunction and PyEval_CallMethod doesn't respect Py_SSIZE_T_CLEAN. We need breaking behavior change for them. And we raise runtime deprecation warning already. I think we should add compile time warning too, regardless # is used or not. > We currently have a deprecation policy saying that functions deprecated > in version N cannot be removed before version N+2. That's a reasonable > policy but some deprecation purists insist that it MUST (instead of MAY) > be removed in version N+2. Following this reasoning, we cannot deprecate > something that we cannot remove. Really? Any example? > > Personally, I think that this reasoning is flawed: even if we cannot > *remove* a function, we can still *deprecate* it. I totally agree with you. Nothing wrong about long deprecation period. > That way, we send a > message that the function shouldn't be used anymore. And it makes it > easier to remove it in the (far) future: if the function was deprecated > for a while, we have a valid reason to remove it. The longer it was > deprecated, the less likely it is to be still used, which makes it > easier to remove eventually. > > So I suggest to embrace such long-term deprecations, where we deprecate > something without planning in advance when it will be removed. This is > actually how most other open source projects that I know handle > deprecations. > > I'd like to know the opinion of the Python core devs here. > FWIW, there is PendingDeprecationWarning for something discouraged but not deprecated, and will be deprecated in the future. But I prefer simple deprecation. Regards, -- Inada Naoki <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4KDQ3QNO4YL6FWX6Q6YQVKPINJ7QK2DG/
