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.hettin...@gmail.com>: > >> On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka <storch...@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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
