Why does _PyUnicode_FromId return a new reference?
Given it returns an eternal object, and it's almost always used temporarily (for attribute lookup, string joining, etc.), it would seem more practical for it to return a borrowed reference. Regards Antoine.
Am 05.11.2011 23:26, schrieb Antoine Pitrou:
Given it returns an eternal object, and it's almost always used temporarily (for attribute lookup, string joining, etc.), it would seem more practical for it to return a borrowed reference.
For purity reasons: all PyUnicode_From* functions return new references (most of them return actually new objects most of the time); having PyUnicode_FromId return a borrowed reference would break uniformity. I personally it difficult to remember which functions return borrowed references, and wish there were fewer of them in the API (with PyArg_ParseTuple being the notable exception where borrowed references are a good idea). Now, practicality beats purity, so the real answer is: I just didn't consider that it might return a borrowed reference. Regards, Martin
Le 06/11/2011 08:08, "Martin v. Löwis" a écrit :
Am 05.11.2011 23:26, schrieb Antoine Pitrou:
Given it returns an eternal object, and it's almost always used temporarily (for attribute lookup, string joining, etc.), it would seem more practical for it to return a borrowed reference.
For purity reasons: all PyUnicode_From* functions return new references (most of them return actually new objects most of the time); having PyUnicode_FromId return a borrowed reference would break uniformity. I personally it difficult to remember which functions return borrowed references, and wish there were fewer of them in the API
I agree with this general sentiment. For PyUnicode_FromId, though, I think it makes sense to return a borrowed reference. Regards Antoine.
participants (2)
-
"Martin v. Löwis" -
Antoine Pitrou