> 1. It can be a str subclass with an overridden __format__. In this case the result will be different.

Thanks! Though this should be possible to do, so not a blocker for suggestion (if I am not missing something)

> 2. If it is a str subclass without an overridden __format__, the optimization adds an overhead for looking up and calling the __format__ method. It can reverse the benefit in this case.

I'll double check, though the compromise seems to make sense considering that %99 of the time this use case is with raw strings.

> 3. It is worth to merge consequent string constants and skip empty string constants. '/'.join([base, 'data', user_arg]) should produce [base, '/data/', user_arg] instead of [base, '/', 'data', '/', user_arg], and ''.join([base, 'data', user_arg]) should produce [base, 'data', user_arg] instead of [base, '', 'data', '', user_arg].

> I believe that the implementation can be optimized further (etc if a continuous block of elements are a string, then we can load all of them in one go!). And some cases proved that the f-strings might be faster than the join by 1.7-1.8x.


I am aware of these possible cases as I stated in the last paragraph, though didn't want to start with them on the PoC. And from what I observe, the speedup goes even further with these.