This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Yonatan Goldschmidt
Recipients Yonatan Goldschmidt, vstinner
Date 2020-11-17.01:04:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605575051.39.0.916351091388.issue42287@roundup.psfhosted.org>
In-reply-to
Content
> I don't see how Py_NewRef() or Py_XNewRef() is less error prone. In my experience, any change is more likely to introduce new bugs than leaving the code unchanged.

Agree that inserting changes opens a door to introducing bugs.

However, the "end state" of having Py_NewRef() is desired, I think. It is more concise. It is less error prone because where you use it, you literally can't miss the "increment refcount" part when stealing a reference from another source. Py_INCREF has to come before/after stealing a ref, leaving room for error, IMHO.

> In general, we don't accept changes which are only coding style changes.

Didn't know that. Well if that's the case, then obviously there is no reason to work specifically on this conversion.
History
Date User Action Args
2020-11-17 01:04:11Yonatan Goldschmidtsetrecipients: + Yonatan Goldschmidt, vstinner
2020-11-17 01:04:11Yonatan Goldschmidtsetmessageid: <1605575051.39.0.916351091388.issue42287@roundup.psfhosted.org>
2020-11-17 01:04:11Yonatan Goldschmidtlinkissue42287 messages
2020-11-17 01:04:10Yonatan Goldschmidtcreate