There are several cases in CPython sources when PyList_AsTuple() is used with just created list and immediately after that this list is Py_DECREFed. This operation can be performed more effectively since refcount of items is not changed. For example it gives such speed-up for BUILD_TUPLE_UNPACK: Before: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 8.75 ms +- 0.10 ms After: $ python -m perf timeit -s "l = [None]*10**6" "(*l,)" ..................... Mean +- std dev: 5.41 ms +- 0.07 ms
-1 This technique has a low payoff (possibly even zero due to memcpy() overhead) but is likely to create future maintenance issues (risk of bugs due to the fragility of assuming a refcnt of one, awkwardness of maintenance if we have to alter the surrounding code).
_PyList_ConvertToTuple(PyObject *v): assert(Py_REFCNT(v) == 1); I don't think that _PyList_ConvertToTuple() usage is common enough to justify this micro-optimization. IMHO "Py_REFCNT(v) == 1" assumption is too strong. Python internals can be very surprising, especially when borrowered references and the garbage collector comes into the game. I concur with Serhiy and Raymond: it's too risky with very low benefit. It is likely to have no significant impact on macro benchmarks like https://pyperformance.readthedocs.io/ ( https://speed.python.org/ ).