On 7 November 2016 at 16:19, Nathaniel Smith <[email protected]> wrote: > On Sun, Nov 6, 2016 at 9:08 PM, C Anthony Risinger <[email protected]> wrote: >> On Nov 6, 2016 7:32 PM, "Nathaniel Smith" <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
