When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

If use _PyUnicodeWriter/_PyBytesWriter, will it be faster?

There are two data contracts that crossing functions:

1. between _parser.parse_template() and _sre.template(). List must be [literal, (group, literal)*]
2. between _sre.template() and expand_template(). chunks = 1 + sum(1+bool(item.literal!=NULL) for item in items)

Such data contracts increase the difficulty of code maintenance. If use _PyUnicodeWriter/_PyBytesWriter, these data contracts are not necessary. And change TemplateObject like this:

typedef struct {
    PyObject_VAR_HEAD
    struct {
        int type; // literal or group
        PyObject *item;
    } items[0];
} TemplateObject;

In the current PR, adjacent groups also waste space.

If use _PyUnicodeWriter/_PyBytesWriter, will it be faster?

I do not think so. The benefit of _PyUnicodeWriter/_PyBytesWriter is that we do not need to allocate an intermediate list and resize it multiple times if the number of items is not known. But in our case it is known, and in common case the buffer allocated on the stack is used. _PyUnicode_JoinArray should be faster because it knows ahead the length and the kind of the result string. _PyUnicodeWriter can perform several memory re-allocations.

I may try to experiment with _PyBytesWriter later. It will complicate the code, so I am not sure it is worth it.

Thank you for review. The conditions of my sight make my to easily miss some details.

I have made the requested changes; please review again.

Thanks for making the requested changes!

@gpshead: please review the changes made to this pull request.

Until there is a clear answer, I plan to suspend work with Serhiy Storchaka.

Please do not do this. Your help compensates my disadvantage.

It doesn't matter, the worst result is to postpone it to a later version.

There are a few possible changes about re module before 3.11 Beta1, #91495, #32411, #91477. Maybe you have other issues to deal with.
I'm afraid if you try too hard, it may be dangerous to your health.

@animalize - While it is great you are concerned for others health, it comes across poorly to say things in an "ultimatum" style such as a "threat" to stop working with someone because they've implied they may have a health concern. This is not kind. In many cultures (including Python's) that conduct is seen as discrimination. It limits others opportunities based on your own presumption of their abilities.

Among committers (which @serhiy-storchaka is a long time member of) none of us expect the steering council to micromanage our lives and most of us would rightfully reject that concept if we were to try. That isn't our purpose. While asking me or the SC to treat another committer specially was presumably voiced out of genuine concern here, it can come across as a put down that belittles their work even if this is not what you intended. We trust everyone to understand their own contribution abilities and act accordingly as they see fit.

Code review collaboration is a way for all of us to fill in gaps in that we all have in our work. Nobody is perfect.

(I'm replying with the above in this forum so that this response is visible to the same audience as the earlier messages that led to it.)

Lets ultimately stay focused on the PR here. Thanks for your reviews!

Sorry. I don't know what to say.

I tried to improve this PR locally, IMHO the data contracts and the buffer[10] optimization make the code harder to understand. (Now I'm working on #91616)

I'll send a PR to serhiy-storchaka:re-compile-template later.

@serhiy-storchaka This PR has been approved by one other core dev, but not merged for some reason. The performance improvement seems worthwhile. Is there a reason why the branch has not been updated? If needed I can help to update the branch to current main

Thanks Serhiy & reviewers!

Thank you Gregory for the final polishing.