[Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

[Nick Coghlan]

On 7 November 2016 at 16:19, Nathaniel Smith <njs at pobox.com> wrote:
> On Sun, Nov 6, 2016 at 9:08 PM, C Anthony Risinger <anthony at xtfx.me> wrote:
>> On Nov 6, 2016 7:32 PM, "Nathaniel Smith" <njs at pobox.com> wrote:
>>>
>>> [...]
>>>
>>> Some other use cases:
>>>
>>> Log some complicated object, but only pay the cost of stringifying the
>>> object if debugging is enabled:
>>>
>>>     log.debug!(f"Message: {message_object!r}")
>>
>> Would the log.debug implementation need to fetch the context to evaluate the
>> delayed expression (say by using sys._getframe) or would that be bound? Is a
>> frame necessary or just a (bound?) symbol table? Could a substitute be
>> provided by on evaluation?
>
> There are a lot of ways one could go about it -- I'll leave the
> details to whoever decides to actually write the PEP :-) -- but one
> sufficient solution would be to just pass AST objects. Those are
> convenient (the compiler has just parsed the code anyway), they allow
> the code to be read or modified before use (in case you want to inject
> variables, or convert to SQL as in the PonyORM case, etc.), and if you
> want to evaluate the thunks then you can look up the appropriate
> environment using sys._getframe and friends. Maybe one can do even
> better, but simple ASTs are a reasonable starting point.

PEP 501 suggested taking the machinery that was added to support
f-string interpolation and making it possible to separate the
expression evaluation and string rendering steps:
https://www.python.org/dev/peps/pep-0501/

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia