I did some quick thinking and a bit of research about some aspects of this
proposal:
There are a number of keyword options (delay, defer, lazy, delayed,
deferred, etc.), a quick look through github says that of these, "deferred"
seems to be the least used, but it still comes up quite a lot (350K times,
lazy appears over 2 million). That's unfortunate, but I'm wondering how
common async and await were when that was proposed and accepted?
Another potential pitfall I'm realizing now (and apologies if this is
unnecessary bikeshedding) is that this may require another keyword. If I
understand the proposal correctly, at this point the suggestion is that
`delayed <EXPR>` delays the evaluation of EXPR until it is requested in a
non-delayed context. That is
>>> x = delayed 1 + 2
>>> y = delayed 3 + 4
>>> z = delayed x + y # neither x nor y has been evaluated yet
>>> z
10
This works fine for simple cases, but there might be situations where
someone wants to control evaluation a bit more. As soon as we add any kind
of state things get icky:
# assuming Foo is a class an attribute `value` and a method
# `inc` that increments the value and returns the current value
>>> foo = Foo(value=0)
>>> x = delayed sum([foo.inc(), foo.inc()])
>>> foo.inc()
1
>>> x
5
However, assuming this is a real, more complex system, we might want a way
to have one or both of those inc calls be eagerly evaluated, which requires
a way of signalling that in some way:
>>> foo = Foo(value=0)
>>> x = delayed sum([foo.inc(), eager foo.inc()])
>>> foo.inc()
2
>>> foo.inc()
4
Perhaps luckily, `eager` is less commonly used than even `delayed`, but
still 2 keywords is an even higher bar. I guess another alternative would
be to require annotating all subexpressions with `delayed`, but then that
turns the above into
>>> foo = Foo(value=0)
>>> x = delayed sum([delayed foo.inc(), delayed foo.inc()])
>>> foo.inc()
1
>>> x
5
At which point `delayed` would need to be a much shorter keyword (the
heathen in me says overload `del`).
--Josh
On Fri, Feb 17, 2017 at 12:13 PM Abe Dillon <abedil...@gmail.com> wrote:
> Actually, following from the idea that packing and unpacking variables
> should be delayed by default, it might make sense to use syntax like:
>
> >>> a = *(2+2)
> >>> b = a + 1
>
> Instead of
>
> >>> a = lazy 2+2 # or whatever you want the keyword to be
> >>> b = a + 1
>
> That syntax sort-of resembles generator expressions, however; I usually
> like how python favors actual words over obscure symbol combinations for
> readability's sake.
>
> On Fri, Feb 17, 2017 at 10:57 AM, Abe Dillon <abedil...@gmail.com> wrote:
>
> I'd like to suggest a shorter keyword: `lazy`
>
> This isn't an endorsement. I haven't had time to digest how big this
> change would be.
>
> If this is implemented, I'd also like to suggest that perhaps packing and
> unpacking should be delayed by default and not evaluated until the contents
> are used. It might save on many pesky edge cases that would evaluate your
> expression unnecessarily.
>
> On Fri, Feb 17, 2017 at 10:43 AM, Joseph Hackman <josephhack...@gmail.com>
> wrote:
>
> Agreed. I think this may require some TLC to get right, but posting here
> for feedback on the idea overall seemed like a good start. As far as I
> know, the basic list and dict do not inspect what they contain. I.e.
>
> d = {}
> d['a']= delayed: stuff()
> b=d['a']
>
> b would end up as still the thunk, and stuff wouldn't be executed until
> either d['a'] or b actually is read from.
>
> -Joseph
>
> > On Feb 17, 2017, at 11:34 AM, Chris Angelico <ros...@gmail.com> wrote:
> >
> >> On Sat, Feb 18, 2017 at 3:29 AM, Joseph Hackman <
> josephhack...@gmail.com> wrote:
> >> ChrisA: I am not sure about collections. I think it may be fine to not
> special case it: if the act of putting it in the collection reads anything,
> then it is evaluated, and if it doesn't it isn't. The ideal design goal for
> this would be that all existing code continues to function as if the change
> wasn't made at all, except that the value is evaluated at a different time.
> >>
> >
> > Yeah, I'm just worried that it'll become useless without that. For
> > instance, passing arguments to a function that uses *a,**kw is going
> > to package your thunk into a collection, and that's how (eg) the
> > logging module will process it.
> >
> > It's not going to be easy to have a simple AND useful definition of
> > "this collapses the waveform, that keeps it in a quantum state", but
> > sorting that out is fairly key to the proposal.
> >
> > ChrisA
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
