On Sun, Oct 31, 2021, 8:59 AM Chris Angelico
> def foo1(a=>[1,2,3], b=>len(a)):
> a.append(4)
> print(b)
>
> And what is the correct behaviour here?
>
> def foo2(a=defer [1,2,3], b=defer len(a)):
> a.append(4)
> print(b)
>
This is a nice example. I agree they are different in the natural reading
of each.
Specifically, suppose both features had been added to the language. I would
expect foo1() to print "3" and foo2() to print "4".
This is also a good example of why the more general feature is BETTER. It
is easy to emulate the foo1() behavior with 'defer', but impossible to
emulate foo2() using '=>'.
E.g.
def foo3(a=defer [1,2,3], b=defer len(a)):
# behaves like foo1()
b = b # or eval_b = b and use new name in body
a.append(4)
print(b)
Note this:
def foo4(a=defer [1,2,3], b=defer len(a))
print(b) # prints 3
In order to print we actually need to walk a DAG. 'b' is an "unevaluated"
object, but the interpreter would need to recognize that it depends on
unevaluated 'a' ... and so on, however far up the tree it needed to walk to
have only regular values (or raise a NameError maybe).
This is all precisely prior art, and is what is done by Dask Delayed:
https://docs.dask.org/en/stable/delayed.html
I think it would be better as actual syntax, but generally Dask already
does what I want.
The amazingly powerful thing about constructing a DAG of deferred
computation is that you can find only intermediate results in a complex
tree if that is all you concretely need.
I recognize that this is more complex than the niche case of late
evaluation of formal parameters. But I consider that niche case trivial,
and certainly not worth special syntax.
In contrast, the niche case falls out seamlessly from the more general idea.
In terms of other prior art, deferred evaluation is the default behavior in
Haskell. I admit that I find strictly functional language with no
mutability a PITA. But inasmuch as Haskell has some elegance, and sometimes
reasonably fast performance, it is largely because delayed evaluation is
baked in.
_______________________________________________
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/DKR6KTOCTJJAGBGQEQWKE2NR3CO5OCSU/
Code of Conduct: http://python.org/psf/codeofconduct/
