[Python-Dev] Deleting with setting C API functions

[Nick Coghlan]

On 2 December 2015 at 22:41, M.-A. Lemburg <mal at egenix.com> wrote:
> On 02.12.2015 13:29, Serhiy Storchaka wrote:
>> On 02.12.15 12:06, Victor Stinner wrote:
>>> 2015-12-02 9:42 GMT+01:00 Serhiy Storchaka <storchaka at gmail.com>:
>>>> You have enough time to update your projects, and you can update them
>>>> uniformly for all versions. And may be you will found few weird bugs related
>>>> to misuse of Set* API.
>>>
>>> Did you check popular projects using C extensions to check if they
>>> call Set*() functions to delete attributes/items?
>>
>> I have checked following projects.
>>
>> regex, simplejson, Pillow, PyQt4, LibreOffice, PyGTK, PyICU, pyOpenSSL, libxml2, Boost, psutil,
>> mercurial don't use PyObject_SetAttr at all.
>>
>> NumPy, pgobject don't use PyObject_SetAttr for deleting.
>>
>> PyYAML and lxml use PyObject_SetAttr only in code generated by Cython and never use it for deleting.
>
> While I don't think deleting attributes is a very common thing
> to do in any Python code base (unless you need to break circular
> references or explicitly want to free resources), the
> fact that PyObject_DelAttr() itself is implemented as macro
> using the NULL attribute value clearly creates an API incompatibility
> when removing this functionality or generating warnings, since
> all code using the correct PyObject_DelAttr() at the moment,
> would then trigger the warning as well.
>
> As a result, the deprecation would have to be extended across
> more releases than the usual cycle.
>
> A first step would be to replace the macro with a proper function
> to avoid false positive warnings, even when using the correct API.
>
> Then we could add a warning to the PyObject_SetAttr() function and
> hope that not too many projects use the stable ABI as basis to
> have C extensions work across several releases.

Ah, I forgot to take the stable ABI guarantee into account - you're
right, it isn't possible to introduce the deprecation without making
an addition to the stable ABI, which would mean extension modules
relying on the stable ABI would need to be rebuilt, rather defeating
the purpose of the stable ABI guarantee.

I think that puts the idea squarely in "we can't do it" territory,
since the benefit on offer through the deprecation process is only a
much easier debugging session when someone is trying to track down the
root cause of an unexpectedly missing attribute on an object.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia