PEP 750: Tag Strings For Writing Domain-Specific Languages

[charliermarsh (Charlie Marsh)]

I’m a fan of the feature in general but find myself agreeing with @erictraut:

@erictraut

However, I have one significant concern. It relates to the deferred evaluation of interpolation expressions. I understand the motivation for this design choice, but I think it has many downsides that are not recognized or addressed in the PEP. The good news is that there are reasonable ways to accommodate lazy evaluation use cases without any of these downsides (more on that later).

My understanding is that JavaScript’s tagged templates (mentioned in the PEP) perform eager evaluation. Personally, I’d like to see stronger motivation and examples for lazy evaluation given the drawbacks mentioned above. I think it will be a source of confusion for users especially because f-strings themselves don’t use these semantics.

@erictraut

Fix 1 (my recommendation): Make deferred execution explicit by having the user provide a callable in the interpolation expression. This fix addresses all of the problems I mentioned above.

I would also prefer this. I find it more intuitive and strictly more flexible, since you can always wrap in a lambda (but not the other way around). If you actually want values to be evaluated lazily, it seems right to me that you should be opting into that.

@MegaIng

Explicitly requiring users to write lambda: breaks the normal reading flow and adds an unnecessary burden that already requires careful documentation reading to use correctly.

I would argue that explicitly requiring users to write lambda: would be both more explicit about the behavior and more intuitive to users given that f-strings are eagerly evaluated, thus reducing the burden to carefully read the documentation.