4 ms·

I'm not sure if t-strings help here? unless I misread the PEP, it seems like they still eagerly evaluate the interpolations. There is an observation that you c

I'm not sure if t-strings help here? unless I misread the PEP, it seems like they still eagerly evaluate the interpolations. There is an observation that you can use `lambda` inside to delay evaluation of an interpolation, but I think this lambda captures any variables it uses from the context.

tylerhou 1y ago
You could do something like t”Hello, {“name”}” (or wrap “name” in a class to make it slightly less hacky).
notpushkin 1y ago
> An early version of this PEP proposed that interpolations should be lazily evaluated. [...] This was rejected for several reasons [...] Bummer. This could have been so useful: statement_endpoint: Final = "/api/v2/accounts/{iban}/statement" (Though str.format isn’t really that bad here either.)
- LordShredda 1y ago
  Would be useful in that exact case, but would be an absolute nightmare to debug, on par with using global variables as function inputs
  - notpushkin 1y ago
    Yeah, to be honest, every time this comes to mind I think “wow, this would be really neat!”, then realize just using .format() explicitly is way easier to read.
- nhumrich 1y ago
  There was a very very long discussion on this point alone, and there are a lot of weird edge cases, and led to weird syntax things. The high level idea was to defer lazy eval to a later PEP if its still needed enough. There are a lot of existing workarounds in the discussions if you are interested enough in using it, such as using lambdas and t-strings together.
- o11c 1y ago
  I do think that people are far too hesitant to bind member functions sometimes: statement_endpoint: Final = "/api/v2/accounts/{iban}/statement".format (it's likely that typecheckers suck at this like they suck at everything else though)
davepeck 1y ago
> I'm not sure if t-strings help here? That's correct, they don't. Evaluation of t-string expressions is immediate, just like with f-strings. Since we have the full generality of Python at our disposal, a typical solution is to simply wrap your t-string in a function or a lambda. (An early version of the PEP had tools for deferred evaluation but these were dropped for being too complex, particularly for a first cut.)
- krick 1y ago
  And that actually makes "Template Strings" a misnomer in my mind. I mean, deferred (and repeated) evaluation of a template is the thing that makes template a template. Kinda messy PEP, IMO, I'm less excited by it than I'd like to be. The goal is clear, but the whole design feels backwards.
  - davepeck 1y ago
    Naming is hard; for instance, JavaScript also has its own template strings, which are also eagerly evaluated.
actinium226 1y ago
> There is an observation that you can use `lambda` inside to delay evaluation of an interpolation, but I think this lambda captures any variables it uses from the context. Actually lambda works fine here >>> name = 'Sue' >>> template = lambda name: f'Hello {name}' >>> template('Bob') 'Hello Bob'
skeledrew 1y ago
Lambda only captures variables which haven't been passed in as argument.

tylerhou 1y ago

You could do something like t”Hello, {“name”}” (or wrap “name” in a class to make it slightly less hacky).

notpushkin 1y ago

> An early version of this PEP proposed that interpolations should be lazily evaluated. [...] This was rejected for several reasons [...] Bummer. This could have been so useful: statement_endpoint: Final = "/api/v2/accounts/{iban}/statement" (Though str.format isn’t really that bad here either.)

LordShredda 1y ago
Would be useful in that exact case, but would be an absolute nightmare to debug, on par with using global variables as function inputs
- notpushkin 1y ago
  Yeah, to be honest, every time this comes to mind I think “wow, this would be really neat!”, then realize just using .format() explicitly is way easier to read.
nhumrich 1y ago
There was a very very long discussion on this point alone, and there are a lot of weird edge cases, and led to weird syntax things. The high level idea was to defer lazy eval to a later PEP if its still needed enough. There are a lot of existing workarounds in the discussions if you are interested enough in using it, such as using lambdas and t-strings together.
o11c 1y ago
I do think that people are far too hesitant to bind member functions sometimes: statement_endpoint: Final = "/api/v2/accounts/{iban}/statement".format (it's likely that typecheckers suck at this like they suck at everything else though)

davepeck 1y ago

> I'm not sure if t-strings help here? That's correct, they don't. Evaluation of t-string expressions is immediate, just like with f-strings. Since we have the full generality of Python at our disposal, a typical solution is to simply wrap your t-string in a function or a lambda. (An early version of the PEP had tools for deferred evaluation but these were dropped for being too complex, particularly for a first cut.)

krick 1y ago
And that actually makes "Template Strings" a misnomer in my mind. I mean, deferred (and repeated) evaluation of a template is the thing that makes template a template. Kinda messy PEP, IMO, I'm less excited by it than I'd like to be. The goal is clear, but the whole design feels backwards.
- davepeck 1y ago
  Naming is hard; for instance, JavaScript also has its own template strings, which are also eagerly evaluated.

actinium226 1y ago

> There is an observation that you can use `lambda` inside to delay evaluation of an interpolation, but I think this lambda captures any variables it uses from the context. Actually lambda works fine here >>> name = 'Sue' >>> template = lambda name: f'Hello {name}' >>> template('Bob') 'Hello Bob'

skeledrew 1y ago

Lambda only captures variables which haven't been passed in as argument.