On 1 Mar 2014 01:22, "Barry Warsaw" <ba...@python.org> wrote: > > On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote: > > >With the new macro in place, the existing Py_CLEAR(x) macro would be > >equivalent to Py_SETREF(x, NULL). > > > >Originally I was also concerned about the "how will people know there's no > >implicit incref?", but I've since become satisfied with the fact that the > >precedent set by the reference stealing SET_ITEM macros is strong enough to > >justify the shorter name. > > I haven't had time to follow this discussion at all, but for a macro to be > called Py_SETREF and *not* increment the reference counter seems at best > confusing. Despite my hesitation to paint a bike shed I haven't had time to > inspect, something more akin to Py_SET_POINTER seems more appropriate > (i.e. don't put "REF" in the name if it isn't playing refcounting games).
It *is* playing refcounting games - it's decrefing the existing target while stealing a reference to the new target, just like the existing SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's more obvious that we will never incref NULL). The whole point of this macro is to take an *existing* reference and safely *overwrite* another existing reference, exactly as the SET_ITEM macros do. That actually gives me an idea that wasn't on Serhiy's original list: Py_SET_ATTR(target, value). After all, setting attributes safely from C is the main use case for this, and I think it strengthens the parallel with the SET_ITEM macros on the concrete types. Cheers, Nick. > > -Barry > _______________________________________________ > 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/ncoghlan%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
