Batuhan Taskaya 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
Serhiy Storchaka added the comment:
I only seen this idiom in the code of Argument Clinic (written by Larry). I am
sure that it is used in third-party code, but I do not know how common is it.
As for the proposed code, checking that the value is a string is not enough.
1. It can be a str sub
Raymond Hettinger added the comment:
I'm also dubious that this would be of value in real code. Looking at the
implementation, it seems to throw way too much code at too small of a problem.
I suspect is is more likely to cause maintenance problems than to produce
noticeable benefits for us
Eric V. Smith added the comment:
> It is a pretty-targeted optimization, so I don't expect it to speed up the
> macro benchmarks. Though that shouldn't be a blocker for small, targeted
> optimizations.
In the past we've rejected optimizations that make the code more complex and
don't result
Batuhan Taskaya added the comment:
> We should check on a real-world benchmark instead of a micro benchmark.
It is a pretty-targeted optimization, so I don't expect it to speed up the
macro benchmarks. Though that shouldn't be a blocker for small, targeted
optimizations.
--
___
Eric V. Smith added the comment:
To be pedantic, f-strings don't "cast" to a string, they call format(obj) on
the argument. Typically this is the same as str(obj), but it need not be. I
guess if all of the arguments are already exact strings then this distinction
doesn't matter, but I'd have
New submission from Batuhan Taskaya :
Since strings are immutable types, we could fold some operation on top of them.
Serhiy has done some work on issue 28307 regarding folding `str % args`
combination, which I think we can extend even further. One simple example that
I daily encounter is tha
