On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D. <david.me...@gmail.com> wrote: > > Hi Martin, > > Short answer: yes, I agree. > Slightly longer: I would be eternally grateful if you wish to contribute to > the PEP with any such expansion of the Motivation and Expansion.
One concern I have, triggered by Martin's Dask, PySpark and Django examples, is that we've seen proposals in the past for "deferred expression" objects that capture an unevaluated expression, and make its AST available for user code to manipulate. The three examples here could all use such a feature, as could other ORMs (and I'm sure there are other use cases). This is in contrast to your proposal, which doesn't seem to help those use cases (if it does, I'd like to understand how). The key distinction seems to be that with your proposal, evaluation is "on reference" and unavoidable, whereas in the other proposals I've seen, evaluation happens on demand (and as a result, it's also possible to work with the expression AST *before* evaluation). My concern is that we're unlikely to be able to justify *two* forms of "deferred expression" construct in Python, and your proposal, by requiring transparent evaluation on reference, would preclude any processing (such as optimisation, name injection, or other forms of AST manipulation) of the expression before evaluation. I suspect that you consider evaluation-on-reference as an important feature of your proposal, but could you consider explicit evaluation as an alternative? Or at the very least address in the PEP the fact that this would close the door on future explicit evaluation models? Paul _______________________________________________ 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/GDMURWK3M4WOQVGEMWFY33ZBRSKQMGYX/ Code of Conduct: http://python.org/psf/codeofconduct/
