[Python-ideas] Delayed Execution via Keyword

[Joseph Jevnik]

About the "whatever is d[k]" in five minutes comment: If I created an
explict closure like: `thunk = lambda: d[k]` and then mutated `d` before
evaluating the closure you would have the same issue. I don't think it is
that confusing. If you need to know what `d[k]` evaluates to right now then
the order of evaluation is part of the correctness of your program and you
need to sequence execution such that `d` is evaluated before creating that
closure.

On Fri, Feb 17, 2017 at 4:17 PM, Joseph Jevnik <joejev at gmail.com> wrote:

> There is no existing code that uses delayed execution so we don't need to
> worry about breaking it. I think it would be much easier to reason about if
> forcing an expression was always explicit. I am not sure what you mean with
> the second case; why are you delaying a function if you care about the
> observable side-effect?
>
> On Fri, Feb 17, 2017 at 4:14 PM, Ed Kellett <edk141 at gmail.com> wrote:
>
>> On Fri, 17 Feb 2017 at 19:38 Joseph Jevnik <joejev at gmail.com> wrote:
>>
>>> Delayed execution and respecting mutable semantics seems like a
>>> nightmare. For most indexers we assume hashability which implies
>>> immutability, why can't we also do that here? Also, why do we need to
>>> evaluate callables eagerly?
>>>
>>
>> Respecting mutability: we just have to always, we don't know if a delayed
>> thing is hashable until we evaluate it. This thing has implications for
>> existing code (since delayed objects can get anywhere) so it should be
>> careful not to do anything too unpredictable, and I think d[k] meaning
>> "whatever is in d[k] in five minutes' time" is unpredictable. One can
>> always delay: d[k] if it's wanted.
>>
>> Evaluate calls: because if you don't, there's no way to say "strictly
>> evaluate x() for its side effects".
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170217/4eeed1ef/attachment.html>