[Python-ideas] Delayed Execution via Keyword

[Abe Dillon]

I'm fairly novice, so I could be way off base here, but it seems like the
inevitable conclusion to this problem is something like JIT compilation,
right? (admittedly, I know very little about JIT compilation)

Python seems to be accumulating a lot of different approaches to achieving
very similar things: asynchronous and/or lazy execution. We have
generators, futures, asyncio, async/await, and probably more that I'm not
thinking of. It seems like it should be possible for the interpreter to
determine when an expression absolutely *must* be evaluated in many cases.
If I write:

>>> log.debug("data = %s", some_expensive_function())

Then it should be possible for python to put off evaluating that function
or even building a full argument tuple if the log level is higher than
debug.

I know code with side-effects, especially I/O related side-effects would be
difficult or impossible to manage within that context (the interpreter
wouldn't be able to know that a write to a file has to occur before a read
from that file for instance. Maybe it would make more sense to mark such
side-effects to tell the interpreter "you must evaluate all deferred
expressions before executing this because it changes stuff that Python
can't keep track of". instead of marking code that the compiler can
optimize.

My gut reaction says this is not the answer because it emphasizes
optimization over correct behavior, but I wanted to share the thought.



On Fri, Feb 17, 2017 at 3:30 PM, Joseph Hackman <josephhackman at gmail.com>
wrote:

> Abe-
>
> You are correct. However I think it may still be salvageable.
>
> In your code example, you could be either making a dict with a key of 1,
> or a set of a delayed object. But there's no reason to build a set of a
> delayed object because hashing it would immediately un-delay.
>
> Similarly, I am not sure delayed should be allowed inside of function
> headers.
>
> So we could say that dictionary keys and sets shouldn't be allowed to use
> the delayed keyword. Same with function headers. Are there any other
> collisions?
>
> -Joseph
>
> On Feb 17, 2017, at 3:41 PM, Abe Dillon <abedillon at gmail.com> wrote:
>
> Couldn't the same thing be true of delayed if it is always followed by a
>> colon?
>
>
> No. Because there are other reasons you'd follow the variable `delayed`
> with a colon:
>
> >>> delayed = 1
> >>> d = {delayed: "oops!"}
>
> My earlier proposal (using unpacking syntax) doesn't work for the same
> reason.
>
> On Fri, Feb 17, 2017 at 2:31 PM, Joseph Hackman <josephhackman at gmail.com>
> wrote:
>
>> Couldn't the same thing be true of delayed if it is always followed by a
>> colon?
>>
>> I.e.
>> delayed=1
>> x= delayed: slow_function()
>> print(delayed) # prints 1
>>
>> -Joseph
>>
>> On Feb 17, 2017, at 2:39 PM, Mark E. Haase <mehaase at gmail.com> wrote:
>>
>> On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton <joshua.morton13 at gmail.com
>> > wrote:
>>
>>> but I'm wondering how common async and await were when that was proposed
>>> and accepted?
>>
>>
>> Actually, "async" and "await" are backwards compatible due to a clever
>> tokenizer hack. The "async" keyword may only appear in a few places (e.g.
>> async def), and it is treated as a name anywhere else.The "await" keyword
>> may only appear inside an "async def" and is treated as a name everywhere
>> else. Therefore...
>>
>>     >>> async = 1
>>     >>> await = 1
>>
>> ...these are both valid in Python 3.5. This example is helpful when
>> proposing new keywords.
>>
>> More info: https://www.python.org/dev/peps/pep-0492/#transition-plan
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170217/f018619c/attachment.html>