On Tue, Jul 16, 2019 at 6:46 PM Jeroen Demeyer
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