Hacker News new | past | comments | ask | show | jobs | submit login

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.




> 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'


> 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.)


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.


Would be useful in that exact case, but would be an absolute nightmare to debug, on par with using global variables as function inputs


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.


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)


> 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.)


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.


Naming is hard; for instance, JavaScript also has its own template strings, which are also eagerly evaluated.


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: