Batuhan Taskaya <isidenti...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44194> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
