On Tue, Jul 6, 2021 at 10:44 AM Guido van Rossum <guido@python.org> wrote:
On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 6/07/21 9:56 am, Jim Baker wrote:
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.
Is there reason to think this will be a common enough requirement to justify having an abbreviated syntax for a parameterless lambda that's only available in template expressions?
If it's just being wrapped in a lambda function, probably nothing, but I think that that would be *very* surprising behaviour. People will expect that the expressions' values will be collected at the point you hit the interpolated string, not later when it gets used.
It would be surprising indeed if this was the *default* behavior, that's why you have to specially mark it using {:...} in Jim's proposal.
IIUC the idea is that the entire template becomes effectively a lambda. It's useful if the evaluation is relatively expensive and may never be needed, e.g. for logging at a level that is off in production. We can debate whether it's better to mark individual substitutions with something like {:...} or whether we should mark the template as a whole (obviously the marking must be understandable by the parser).
Ahh, I see what you mean. It'll still be surprising at times (cf the bizarre issues that can happen with mutable objects and Chrome's JS developer tools), but could be beneficial, yeah. ChrisA