[Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API

[Victor Stinner]

Recently, Oren Milman fixed multiple bugs when an __init__() method
was called twice. IMHO Py_SETREF() was nicely used in __init__():

https://github.com/python/cpython/commit/e56ab746a965277ffcc4396d8a0902b6e072d049

https://github.com/python/cpython/commit/c0cabc23bbe474d542ff8a4f1243f4ec3cce5549

While it's possible to rewrite the code *correctly* without
PY_SETREF(), it would be much more verbose. Here the fix remains a
single line:

- self->archive = filename;
+ Py_XSETREF(self->archive, filename);

Victor

2017-11-09 3:08 GMT+01:00 Raymond Hettinger <raymond.hettinger at gmail.com>:
>
>> On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka <storchaka at gmail.com> wrote:
>>
>> Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all maintained versions ([1] and [2]). Despite their names they are private. I think that they are enough stable now and would be helpful in third-party code. Are there any objections against adding them to the stable C API? [3]
>
> I have mixed feeling about this.  You and Victor seem to really like these macros, but they have been problematic for me.  I'm not sure whether it is a conceptual issue or a naming issue, but the presence of these macros impairs my ability to read code and determine whether the refcounts are correct.  I usually end-up replacing the code with the unrolled macro so that I can count the refs across all the code paths.
>
> The other issue is that when there are multiple occurrences of these macros for multiple variables, it interferes with my best practice of deferring all decrefs until the data structures are in a fully consistent state.  Any one of these can cause arbitrary code to run.  I greatly prefer putting all the decrefs at the end to increase my confidence that it is okay to run other code that might reenter the current code.  Pure python functions effectively have this built-in because the locals all get decreffed at the end of the function when a return-statement is encountered.  That practice helps me avoid hard to spot re-entrancy issues.
>
> Lastly, I think we should have a preference to not grow the stable C API.  Bigger APIs are harder to learn and remember, not so much for you and Victor who use these frequently, but for everyone else who has to lookup all the macros whose function isn't immediately self-evident.
>
>
> Raymond
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com