Mailing List Archive

Long-term deprecation policy
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.

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.

Personally, I think that this reasoning is flawed: even if we cannot
*remove* a function, we can still *deprecate* it. 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.


Cheers,
Jeroen.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/IRUNBGU3GN4XGTXWKFFZZJR7XDOWZWWF/
Re: Long-term deprecation policy [ In reply to ]
On Tue, Jul 16, 2019 at 6:46 PM Jeroen Demeyer <J.Demeyer@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 <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/
Re: Long-term deprecation policy [ In reply to ]
On 2019-07-16 15:33, Inada Naoki wrote:
>> 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?

* https://bugs.python.org/issue29548#msg287775

*
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/10
and following
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/QUPCYUHYAY5UX7NIBGJ5FVY5EHHIK442/
Re: Long-term deprecation policy [ In reply to ]
Jeroen Demeyer 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.
> We currently have a deprecation policy saying that functions deprecated
> in version N cannot be removed before version N+2.

Do we have that officially written down anywhere? The closest I know is https://www.python.org/dev/peps/pep-0387/ but that PEP is still a draft.

And for me the "official" policy is if you deprecate in N you can remove in N+1, not N+2. (But all of this is a bit wonky with Python 2.7 still being alive and not being able to remove anything from the stdlib unless it's severely broken until 2.7 hits EOL).

> 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.
> Personally, I think that this reasoning is flawed: even if we cannot
> remove a function, we can still deprecate it. 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.

I prefer removal for ease of maintenance (people always want to update code even if it's deprecated), and to help make sure people who don't read the docs but discover something via the REPL or something and don't run with warnings on do not accidentally come to rely on something that's deprecated.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/PRI2O6G6O6HUVGXD3W2MSCEF4JTW36IB/
Re: Long-term deprecation policy [ In reply to ]
On 2019-07-17 02:34, Brett Cannon wrote:
> I prefer removal for ease of maintenance (people always want to update code even if it's deprecated), and to help make sure people who don't read the docs but discover something via the REPL or something and don't run with warnings on do not accidentally come to rely on something that's deprecated.

I see what you mean but it doesn't really answer my question.

I was asking about a scenario where you plan on purpose a long
deprecation period because you know in advance that you cannot remove
the functionality soon (because of PEP 384 or because it's used a lot,
for example collections ABCs).
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GLFWX7QJ7WKNHHWXJEXMJI5JDCTIGODF/
Re: Long-term deprecation policy [ In reply to ]
On Tue, Jul 16, 2019 at 11:07 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
>
> On 2019-07-16 15:33, Inada Naoki wrote:
> >> 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?
>
> * https://bugs.python.org/issue29548#msg287775
>

OK, Stable ABI was special. We can not remove it until Python 4
regarding to PEP 384.
In 2017, Python 4 was looked like "forever". But for now, we should
think Python 4 is
the real future in 2020s, not 3000 or 4000.

I think we should deprecate APIs in stable API like non-stable API if
we want to remove
it after Python 4.0.

--
Inada Naoki <songofacandy@gmail.com>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/WR4SE2GFZHW2CFD6C7Z4BI7A2FWK5SMQ/
Re: Long-term deprecation policy [ In reply to ]
Jeroen Demeyer wrote:
> On 2019-07-17 02:34, Brett Cannon wrote:
> > I prefer removal for ease of maintenance (people
> > always want to update code even if it's deprecated), and to help make sure people who
> > don't read the docs but discover something via the REPL or something and don't run with
> > warnings on do not accidentally come to rely on something that's deprecated.
> > I see what you mean but it doesn't really answer my question.
> I was asking about a scenario where you plan on purpose a long
> deprecation period because you know in advance that you cannot remove
> the functionality soon (because of PEP 384 or because it's used a lot,
> for example collections ABCs).

Sorry, I misread the question you were asking. Yes, I agree that even if you can't remove something for a while you should still deprecate it.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/265QKTU3MDYMDZQ6MHZRPTELSZFURU46/
Re: Long-term deprecation policy [ In reply to ]
On Wed, Jul 17, 2019 at 2:36 AM Brett Cannon <brett@python.org> wrote:
>
> Jeroen Demeyer 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.
> > We currently have a deprecation policy saying that functions deprecated
> > in version N cannot be removed before version N+2.
>
> Do we have that officially written down anywhere? The closest I know is https://www.python.org/dev/peps/pep-0387/ but that PEP is still a draft.
>
> And for me the "official" policy is if you deprecate in N you can remove in N+1, not N+2. (But all of this is a bit wonky with Python 2.7 still being alive and not being able to remove anything from the stdlib unless it's severely broken until 2.7 hits EOL).
>

See also https://mail.python.org/archives/list/python-dev@python.org/thread/ZUKVACWVX7SQEA7FGZRXALR7PWCLV7K6/
Some things changed since that thread, but some points are still valid.

> > 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.
> > Personally, I think that this reasoning is flawed: even if we cannot
> > remove a function, we can still deprecate it. 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.
>
> I prefer removal for ease of maintenance (people always want to update code even if it's deprecated), and to help make sure people who don't read the docs but discover something via the REPL or something and don't run with warnings on do not accidentally come to rely on something that's deprecated.
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@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/PRI2O6G6O6HUVGXD3W2MSCEF4JTW36IB/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/GQDFRX3K6DIWYSRZNAW2AIOUCGHSZWA4/