GeezerVison

Deprecation added by issue #69887. cc @serhiy-storchaka @vadmium

I would prefer that either we fully removed these deprecations, or to really deprecate them: emit DeprecationWarning at runtime.

What is changed since it was discussed 8 years ago?

What is changed since it was discussed 8 years ago?

I would like to clarify what is really deprecated or not in Python 3.13. I don't see the value of a mention of a deprecation in the documentation without using .. deprecated:: markup and without emitting a DeprecationWarning at runtime.

IMO passing NULL is just fine, it's not going to change, so there is no need to deprecate it.

In 2015, you wrote:

I think the conclusion of Python_Dev discussion is that it is not worth to deprecate this behavior in the code.

So well, I propose to actually not deprecate it :-D

The Gmane link no longer work, the working links to the discussion (it was split on several threads) are
https://mail.python.org/archives/list/[email protected]/thread/OSKS23WDHU67NQCANPNSAPHATZ2J3W7T/
https://mail.python.org/archives/list/[email protected]/thread/UJI3KJQVOY7VELTDJOBTBWM3TYDHEYGD/

The problems with the current behavior:

1. It looks confusing that some of *Set* functions do removing, while other raise SystemError or crash. Ideally, all such functions should either support deletion by specifying NULL, or raise SystemError. A crash is acceptable too, for performance.
2. It is a bug magnet. It is easy to get the NULL pointer instead of a pointer to object (just forgot to check for error) and delete instead of set.

Changing the current behavior is a long process. M.-A. Lemburg specified the required procedure. It is interesting, that if we started it in 3.6, it would already be finished.

I reported this error prone API as capi-workgroup/problems#47

It is a bug magnet. It is easy to get the NULL pointer instead of a pointer to object (just forgot to check for error) and delete instead of set.

Oh right. I would prefer to emit a DeprecationWarning in this case and prepare a migration plan towards "Del" functions instead. I don't think that a sentence in the documentation is enough to help users to avoid mistakes.

I created a discussion to specify "Soft Deprecation" in PEP 387: https://discuss.python.org/t/formalize-the-concept-of-soft-deprecation-dont-schedule-removal-in-pep-387-backwards-compatibility-policy/27957

I close this PR in favor of issue #106572: Deprecate PyObject_SetAttr(obj, name, NULL): PyObject_DelAttr(obj, name) must be used instead.