All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

You need to sign the CLA.

Requesting @encukou who wanted to finish this per #1011 (comment)

This looks good now. I'll let @serhiy-storchaka have a look as well.

thanks for the review @picnixz ! 🙏

Sorry for ignoring this PR earlier. It did not looked important to me, and I was no longer sure about its usefulness, because path is usually so long.

Why use PyUnicodeWriter at first place? Does it make the code smaller/clearer? Is the performance difference too large?

@picnixz recommended PyUnicodeWriter in #136770 (comment)

What were the problems with recreating the strings? Do you have any benchmark data?

@serhiy-storchaka, what would be your preferred alternative to PyUnicodeWriter? As far as I know, @vstinner added it exactly for use cases like this.

The original PR used PyUnicode_Substring() and PyUnicode_FromFormat() (similar code is also used in other places). It was pretty compact, half as short as the current code in this PR. It had also fast path for the case without keyword argument. I ask what are the benefits of the larger code. Is it performance? I would like to see the data.

The original PR used PyUnicode_Substring() and PyUnicode_FromFormat() (similar code is also used in other places). It was pretty compact, half as short as the current code in this PR. It had also fast path for the case without keyword argument. I ask what are the benefits of the larger code. Is it performance? I would like to see the data.

@serhiy-storchaka Please see a small benchmark test of the two alternatives here Yoav11#1
at least from this naive test it would appear to me that the PyUnicdeWriter implementation is ~25% faster. Lmk if you would like me to change the benchmark / try a different test case

The code is bigger because it uses an extra function call rather than %s with hasargs ? ", " : "". It would be possible to do that with PyUnicodeWriter_Format too, and get back to roughly the same size of code.
I personally find the if (hasargs) {PyUnicodeWriter_WriteASCII(...)} more readable.

Merged, thanks.

thank you @vstinner @serhiy-storchaka @encukou @StanFromIreland @picnixz ! 🚀 🐍