[Python-ideas] Delayed Execution via Keyword
edk141 at gmail.com
Fri Feb 17 19:28:13 EST 2017
On Fri, 17 Feb 2017 at 23:14 Joshua Morton <joshua.morton13 at gmail.com>
> @ 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
> 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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas