Sorry, but I think all this talk about lazy evaluation is a big red herring:
(1) Python is not Haskell or Dask.
(2) Lazy evaluation is something Python doesn't have, and would be
a HUGE amount of work for Chris (or anyone) to implement (much more, I
would think, than he has already put into his reference implementation
of PEP 671). It's effectively asking for an implementation of that
deferred evaluation vapourware that people keep talking about. It's not
going to happen in a foreseeable time frame. And in the unlikely event
that Chris (or someone) DID implement it, I expect there would be a
chorus of "No, no, that's not how (I think) it should work at all".
(3) Late-bound defaults that are evaluated at function call time,
as per PEP 671, give you an easy way of doing something that at present
needs one of a number of workarounds (such as using sentinel values) all
of which have their drawbacks or awkward points.
(4) The guarantee that a late-bound default WILL be executed at
function call time, can be useful, even essential (it could be
time-dependent or it could depend on the values - default or otherwise -
of other parameters whose values might be changed in the function
body). Sure, I appreciate that there are times when you might want to
defer the evaluation because it is expensive and might not be needed, but:
(5) If you really want deferred evaluation of a parameter default,
you can achieve that by explicitly evaluating it, *at the point you want
it*, in the function body. Explicit is better than implicit.
Sorry again, but IMO discussing any model except one where late-bound
defaults are evaluated at function call time is just adding FUD.
I suppose I'll be accused again of trying to censor this thread for
saying that. Well, as Chris said (as far as I recall ATM) there is a
difference between discussing variants of a proposal and discussing
orthogonal proposals (which could be raised in a separate thread). And
IMO lazy evaluation IS a different, orthogonal proposal. There's
nothing in the PEP about it.
Best wishes
Rob Cliffe
On 18/06/2022 16:42, David Mertz, Ph.D. wrote:
I think the example that Steven gave, and Stephen approximately
repeats is good.
def func(items=[], n=later len(items)):
items.append("Hello")
print(n)
func()
> I guess Chris will say 0 and David will say 1, but I might be wrong
about either of them.
This is correct. And even though using a (soft) keyword like this gets
me to -0, the semantics I want indeed are different. I only want the
binding to be evaluated when it is referenced. If it never gets
referenced, the compassion time asked side effects are skipped.
Of course, the first line of the function body could be `n = n`. But
adding that line isn't so much different from starting with `if n is
None: n = ... `
As to Stephen's comments on not having used the "evaluate on
reference" pattern, that's pretty much not having used dask.deferred.
The difference is that with Dask (or Haskell) everything stays lazy
until you explicitly call `.compute()` on something in the DAG of
operations. I'd prefer not to need that.
But then my not-a-proposal would need a way to have "a reference that
isn't a reference". I think the same keywords works.
def func(items=[], n=later len(items)):
items.append("Hello")
n = later n**3 # n remains lazy
# ... more stuff
print(n) # actually evaluate the cube of length
On Sat, Jun 18, 2022, 10:52 AM Stephen J. Turnbull
<stephenjturnb...@gmail.com> wrote:
Chris wants syntax for the common pattern
def foo(arg_with_new_empty_list_default=None):
if arg_with_new_empty_list_default is None:
arg_with_new_empty_list_default = []
# do stuff
I can't really guess how useful the "use point" version would be.
It's not a pattern I've used, I use a zero-argument function very
occasionally but I can't recall a case where I used a lambda
_______________________________________________
Python-ideas mailing list --python-ideas@python.org
To unsubscribe send an email topython-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived
athttps://mail.python.org/archives/list/python-ideas@python.org/message/RLFYYFG7T53F7XGFGWMTV3NWHWVP3LCU/
Code of Conduct:http://python.org/psf/codeofconduct/
_______________________________________________
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/RIVWFMBG47ILJNEVNMACCTE7YS7RWGGL/
Code of Conduct: http://python.org/psf/codeofconduct/
