On Tue, 6 Jul 2021, 7:56 am Jim Baker, <jim.ba...@python.org> wrote: > > > On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum <gu...@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. >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/H6VVZ46MAE74EQXC5PONVIVWIHMSGNMX/ Code of Conduct: http://python.org/psf/codeofconduct/
