That's seems like the wrong pattern, maybe I'm missing something.

Ruby has lazy evaluation with a generic lazy enumeration facility, whether to produce string or any kind of object.

That is, I don't know what is the actual behavior of the default string interpolation in Ruby, but if profiling a codebase some string generation would gain lazy evaluation, there is a path to do so. But in the general case, does it really matter? Chances are good that a string construction is not a big bottleneck.

Does Python miss such a feature of generic lazy enumeration, or is it so painful to use that some syntactic sugar felt like a must have? Genuine question here, I don't have any strong opinion on this t-string feature.

▲ BiteCode_dev 3 months ago | parent [-]

It has lazy enumeration with generators, but:

    - string construction is a hot path, you don't want them to always be lazy, especially since any access is slow in python.

    - having it using a string syntax is just very clean and easy to read. It's explicit and can be supported by good editor highlighting.

    - it's easy to grep, analyse for, substitute, etc.

    - you get one single unified API instead of thousands of variations. Translations API, log API and escaping API can all look the same, arguments are in the same shapes.

	▲	psychoslave 3 months ago \| parent [-]
		Thanks for the detailed answer. I understand that string generation can be a hotpath, though I wouldn't take it as a general certain fact. From what I understand here the benefit in term of performance is mainly due to partial application automatically handled by the interpreter. It's hard to me to jauge actual pro/con compared to Ruby which can also leverage on freezed string, lambda, miscellaneous lazy evaluation facilities for example. I'm not aware of anything close in PHP, to stay in the realm of popular interpreted languages. I didn't make any Lua for a long time, so no idea how it evolved on that matter.