Hey! Excellent feedback! In my mind, which word is selected doesn't matter much to me. I think the technical term is 'thunk'? I think delayed is most clear.
I'm not sure if eager execution is so common in this framework it needs its own keyword. Notably, default Python will handle that case x= Delayed: sum((foo.inc(), foo.inc())) Can become y=foo.inc() x= delayed: sum((foo.inc(), y)) It's less sugary, but seems ok to me. How does that seem? -Joseph > On Feb 17, 2017, at 1:55 PM, Joshua Morton <joshua.morto...@gmail.com> wrote: > > 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/