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@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@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@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@gmail.com> wrote:
On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton <joshua.morton13@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@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/