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/
