gh-90699: Use _Py_STR(empty) instead of PyUnicode_New(0, 0) #91476
Conversation
Modules/_ctypes/_ctypes.c
Outdated
| @@ -4635,7 +4635,7 @@ Array_subscript(PyObject *myself, PyObject *item) | |||
| wchar_t *dest; | |||
|
|
|||
| if (slicelen <= 0) | |||
| return PyUnicode_New(0, 0); | |||
| return Py_NewRef(&_Py_STR(empty)); | |||
There was a problem hiding this comment.
Out of curiosity, what is the benefit of this change except inline calling?
AFAIK, PyUnicode_New(0, 0); will finally call unicode_get_empty which is the same replacement of _Py_STR(empty)
cpython/Objects/unicodeobject.c
Lines 1372 to 1377 in f33e2c8
cpython/Objects/unicodeobject.c
Lines 259 to 271 in f33e2c8
There was a problem hiding this comment.
AFAIK, @ericsnowcurrently try to reduce private API from the stdlib module as the best practice for 3rd party users who try to write C extension module by referencing stdlib implementation..
So I don't think this is a good replacement if there are no significant improvements.
Please let me know if I know wrong Eric :)
There was a problem hiding this comment.
That makes sense. I had first seen that ceval.c could change, so I made similar changes elsewhere, but if the other code is better left alone, I don't mind.
I updated this PR to only have the ceval.c change, where the code can actually get smaller and have fewer branches.
LGTM
I am +1 with an aggressive optimization approach for opcode evaluation :)
No description provided.