On 21 December 2015 at 23:46, Serhiy Storchaka <storchaka at gmail.com> wrote: > On 16.12.15 16:12, Serhiy Storchaka wrote: >> >> Please put your vote (a floating number from -1 to 1 including) for >> every of proposed name. You also can propose new name. > > > Thank you all for your votes. > > Results of the poll: > > Py_SETREF: +5 = +5 (Victor, Steve, Yury, Brett, Nick) +0 (Ryan, Martin) > > Py_REPLACE_REF: +2.5 = +2.5 (Ryan, Victor, Steve, Martin) -0 (Nick) > > Py_REPLACE: +0 = +1 (Martin) -1 (Ryan) +0 (Nick) > > Py_RESET: 0 = +1 (Ryan) -1 (Martin) > > Py_DECREF_REPLACE: -2 = +1 (Ryan, Martin) -3 (Victor, Steve, Nick) > > Py_SET_POINTER, Py_SET_ATTR: -5 (Ryan, Victor, Steve, Martin, Nick) > > Therefore Py_SETREF is the winner. > > But I want also to remember objections against it formulated in previous > discussion. > > 1) By analogy with Py_INCREF and Py_DECREF that increment and decrement the > reference counter of the object, Py_SETREF looks as it *sets* the reference > counter of the object. > > 2) By analogy with PyList_SET_ITEM, PyTuple_SET_ITEM, PyCell_SET, etc, it is > not expected that Py_SETREF decrement the refcounter of the old value before > overwriting it. Avoiding those misleading associations is a good argument in favour of Py_REPLACE over Py_SETREF - they didn't occur to me before casting my votes, and I can definitely see them causing confusion in the future. So perhaps the combination that makes the most sense is to add Py_REPLACE (uses Py_DECREF on destination) & Py_XREPLACE (uses Py_XDECREF on destination) to the existing Py_CLEAR? Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4