Hi David, I read the PEP and I think it would be useful to expand the Motivation and Examples sections. While indeed Dask uses lazy evaluation to build a complex computation without executing it, I don't think that it is the whole story. Dask takes this deferred complex computation and *plans* how to execute it and then it *executes* it in non-obvious/direct ways. For example, the computation of the min() of a dataframe can be done computing the min() of each partition of the dataframe and then computing the min() of them. Here is where the plan and the execution stages play. All of this is hidden from the developer. From his/her perspective the min() is called once over the whole dataframe. Dask's deferred computations are "useless" without the planning/execution plan. PySpark, like Dask, does exactly the same. But what about Django's ORM? Indeed Django allows you the build a SQL query without executing it. You can then perform more subqueries, joins and group by without executing them. Only when you need the real data the query is executed. This is another example of deferred execution similar to Dask/PySpark however when we consider the planning/execution stages the similarities ends there. Django's ORM writes a SQL query and send it to a SQL database. Another example of deferred execution would be my library to interact with web pages programmatically: selectq. Very much like an ORM, you can select elements from a web page, perform subselections and unions without really interacting with the web page. Only when you want to get the data from the page is when the deferred computations are executed and like an ORM, the plan done by selectq is to build a single xpath and then execute it using Selenium. So... Three cases: Dask/PySpark, Django's ORM and selectq. All of them implement deferred expressions but all of them "compute" them in very specific ways (aka, they plan and execute the computation differently). Would those libs (and probably others) do benefit from the PEP? How? Thanks, Martin. On Tue, Jun 21, 2022 at 04:53:44PM -0400, David Mertz, Ph.D. wrote:
Here is a very rough draft of an idea I've floated often, but not with much specification. Take this as "ideas" with little firm commitment to details from me. PRs, or issues, or whatever, can go to https://github.com/DavidMertz/peps/blob/master/pep-9999.rst as well as mentioning them in this thread.
PEP: 9999 Title: Generalized deferred computation Author: David Mertz <dmertz@gnosis.cx> Discussions-To: https://mail.python.org/archives/list/python-ideas@python.org/thread/ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 21-Jun-2022 Python-Version: 3.12 Post-History:
Abstract ========
This PEP proposes introducing the soft keyword ``later`` to express the concept of deferred computation. When an expression is preceded by the keyword, the expression is not evaluated but rather creates a "thunk" or "deferred object." Reference to the deferred object later in program flow causes the expression to be executed at that point, and for both the value and type of the object to become the result of the evaluated expression.
Motivation ==========
"Lazy" or "deferred" evaluation is useful paradigm for expressing relationships among potentially expensive operations prior their actual computation. Many functional programming languages, such as Haskell, build laziness into the heart of their language. Within the Python ecosystem, the popular scientific library `dask-delayed <dask-delayed>`_ provides a framework for lazy evaluation that is very similar to that proposed in this PEP.
.. _dask-delayed: https://docs.dask.org/en/stable/delayed.html
Examples of Use ===============
While the use of deferred computation is principally useful when computations are likely to be expensive, the simple examples shown do not necessarily use such expecially spendy computations. Most of these are directly inspired by examples used in the documentation of dask-delayed.
In dask-delayed, ``Delayed`` objects are create by functions, and operations create a *directed acyclic graph* rather than perform actual computations. For example::
import dask @dask.delayed ... def later(x): ... return x ... output = [] data = [23, 45, 62] for x in data: ... x = later(x) ... a = x * 3 ... b = 2**x ... c = a + b ... output.append(c) ... total = sum(output) total Delayed('add-8f4018dbf2d3c1d8e6349c3e0509d1a0') total.compute() 4611721202807865734 total.visualize()
.. figure:: pep-9999-dag.png :align: center :width: 50% :class: invert-in-dark-mode
Figure 1. Dask DAG created from simple operations.
Under this PEP, the soft keyword ``later`` would work in a similar manner to this dask.delayed code. But rather than requiring calling ``.compute()`` on a ``Delayed`` object to arrive at the result of a computation, every reference to a binding would perform the "compute" *unless* it was itself a deferred expression. So the equivalent code under this PEP would be::
output = [] data = [23, 45, 62] for later x in data: ... a = later (x * 3) ... b = later (2**x) ... c = later (a + b) ... output.append(later c) ... total = later sum(output) type(total) # type() does not un-thunk <class 'DeferredObject'> if value_needed: ... print(total) # Actual computation occurs here 4611721202807865734
In the example, we assume that the built-in function `type()` is special in not counting as a reference to the binding for purpose of realizing a computation. Alternately, some new special function like `isdeferred()` might be used to check for ``Deferred`` objects.
In general, however, every regular reference to a bound object will force a computation and re-binding on a ``Deferred``. This includes access to simple names, but also similarly to instance attributes, index positions in lists or tuples, or any other means by which an object may be referenced.
Rejected Spellings ==================
A number of alternate spellings for creating a ``Deferred`` object are possible. This PEP-author has little preference among them. The words ``defer`` or ``delay``, or their past participles ``deferred`` and ``delayed`` are commonly used in discussions of lazy evaluation. All of these would work equally well as the suggested soft keyword ``later``. The keyword ``lazy`` is not completely implausible, but does not seem to read as well.
No punctuation is immediately obvious for this purpose, although surrounding expressions with backticks is somewhat suggestive of quoting in Lisp, and perhaps slightly reminiscent of the ancient use of backtick for shell commands in Python 1.x. E.g.::
might_use = `math.gcd(a, math.factorial(b))`
Relationship to PEP-0671 ========================
The concept of "late-bound function argument defaults" is introduced in :pep:`671`. Under that proposal, a special syntactic marker would be permitted in function signatures with default arguments to allow the expressions indicated as defaults to be evaluated at call time rather than at runtime. In current Python, we might write a toy function such as::
def func(items=[], n=None): if n is None: n = len(items) items.append("Hello") print(n)
func([1, 2, 3]) # prints: 3
Using the :pep:`671` approach this could be simplified somewhat as::
def func(items=[], n=>len(items)): # late-bound defaults act as if bound here items.append("Hello") print(n)
func([1, 2, 3]) # prints: 3
Under the current PEP, evaluation of a ``Deferred`` object only occurs upon reference. That is, for the current toy function, the evaluation would not occur until the ``print(n)`` line.::
def func(items=[], n=later len(items)): items.append("Hello") print(n)
func([1, 2, 3]) # prints: 4
To completely replicate the behavior of PEP-0671, an extra line at the start of the function body would be required::
def func(items=[], n=later len(items)): n = n # Evaluate the Deferred and re-bind the name n items.append("Hello") print(n)
func([1, 2, 3]) # prints: 3
References ==========
https://github.com/DavidMertz/peps/blob/master/pep-9999.rst
Copyright =========
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/DQTR3C... Code of Conduct: http://python.org/psf/codeofconduct/