On Tue, 6 Jul 2021, 7:56 am Jim Baker, <jim.baker@python.org> wrote:


On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum <guido@python.org> wrote:
FWIW, we could make f-strings properly nest  too, like you are proposing for backticks. It's just that we'd have to change the lexer. But it would not be any harder than would be for backticks (since it would be the same algorithm), nor would it be backward incompatible. So this is not an argument for backticks.

Good point. At some point, I was probably thinking of backticks without a tag, since JS supports this for their f-string like scenario. but if we always require a tag - so long as it's not a prefix already in use (b, f, r, fr, hopefully not forgetting as I type this email in a parking lot...) - then it can be disambiguated using standard quotes.

There's a deferred PEP proposing a resolution to the f-string nesting limitations: 
https://www.python.org/dev/peps/pep-0536/#motivation



Separately, should there be a way to *delay* evaluation of the templated expressions (like we explored in our private little prototype last year)?

I think so, but probably with an explicit marker on *each* deferred expression. I'm in favor of Julia's expression quote, which generally needs to be enclosed in parentheses, but possibly not needed in  expression braces (at the risk of looking like a standalone format spec). https://docs.julialang.org/en/v1/manual/metaprogramming/

So this would like
x = 42
d = deferred_tag"Some expr: {:(x*2)}"

All that is happening here is that this being wrapped in a lambda, which captures any scope lexically as usual. Then per that experiment you mentioned, it's possible to use that scope using fairly standard - or at least portable to other Python implementations - metaprogramming, including the deferred evaluation of the lambda.
(No frame walking required!)

Other syntax could work for deferring.

It reminds me of the old simple implicit lambda proposal: https://www.python.org/dev/peps/pep-0312/

The old proposal has more ambiguities to avoid now due to type hinting syntax but a parentheses-required version could work: "(:call_result)" 

Cheers,
Nick.