The more I think about this, the more sense it makes to leave the module in unicodeobject.c. Certainly all the code it's likely to ever contain would already be in unicodeobject.c.

While I agree there's some conceptual clarity to be had by having the code in a new Modules/_stringmodule.c (and indeed, that's the first place I'd go if I were looking for it), I think that practically it might make sense to leave it in unicodeobject.c.

On the other hand, there are no modules defined in Objects/*.c, so this is clearly an unusual and unexpected practice.

Maybe a first step would be to commit Georg's patch as-is. Later I'll get rid of stringlib (at least for format()), then at that point rethink where any module should live.

I note that Georg's code doesn't need any tests because the affected code in string.py is already tested and will fail if the module is moved.