[Python-ideas] Delayed Execution via Keyword

[Ed Kellett]

On Fri, 17 Feb 2017 at 23:14 Joshua Morton <joshua.morton13 at gmail.com>
wrote:

> @ Ed
>
> Its my understanding that d[k] is always d[k], even if d or k or both are
> delayed. On the other hand, `delayed d[k]` would not be, but you would need
> to explicitly state that. I think its worth expanding on the example Joseph
> made.
>
> I think it makes sense to consider this proposal to be `x = delayed
> <EXPR>` is essentially equivalent to `x = lambda: <EXPR>`, except that
> there will be no need to explicitly call `x()` to get the delayed value,
> instead it will be evaluated the first time its needed, transparently.
> This, for the moment, assumes that this doesn't cause enormous interpreter
> issues, but I don't think it will. That is, there is no "delayed" object
> that is created and called, and so as a user you really won't care if an
> object is "delayed" or not, you'll just use it and it will be there.
>
> Do you understand this proposal differently?
>
> --Josh
>

Chris mentioned something about it being difficult to decide what evaluates
a delayed thing, and what maintains it. This tangent started with my
suggesting that operators should maintain delayed-ness iff all their
operands are delayed, with ., [] and () as exceptions. That is, I'm
suggesting that d[k] always evaluate d and k, but a + b might defer
evaluation if a and b are both delayed already. Roughly, I guess my
rationale is something like "let operators combine multiple delayed-objects
into one, unless that would break things"—and at least by convention,
operators that aren't ., [] or () don't have behaviour that would be broken.

Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170218/98b581c7/attachment-0001.html>