▲ | mortar 9 days ago | ||||||||||||||||||||||||||||
> If a single interpolation is expensive to evaluate, it can be explicitly wrapped in a lambda in the template string literal I’m having trouble understanding this - Can someone please help out with an example use case for this? It seems like before with an f string we had instant evaluation, now with a t string we control the evaluation, why would we further delay evaluation - Is it just to utilise running a function on a string first (i.e. save a foo = process(bar) line?) | |||||||||||||||||||||||||||||
▲ | cstrahan 9 days ago | parent | next [-] | ||||||||||||||||||||||||||||
> It seems like before with an f string we had instant evaluation, now with a t string we control the evaluation You don't completely control the evaluation. From the PEP: > Template strings are evaluated eagerly from left to right, just like f-strings. This means that interpolations are evaluated immediately when the template string is processed, not deferred or wrapped in lambdas. If one of the things you are interpolating is, as a silly example, an invocation of a slow recursive fibonacci function, the template string expression itself (resulting in a Template object) will take a long while to evaluate. | |||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||
▲ | smitty1e 9 days ago | parent | prev [-] | ||||||||||||||||||||||||||||
So that you can calculate the string in A.py and then use it over in B.py . |