Steven D'Aprano <steve@pearwood.info> ezt írta (időpont: 2019. szept. 16., H 2:55):
On Mon, Sep 16, 2019 at 11:36:45AM +1200, Greg Ewing wrote:
> George Fischhof wrote:
> >With this syntax the use / programmer do not have to write async def,
> >nor await, because after the yield the await should come automatically.
>
> I don't see how you can eliminate the await in your example generator.
> Can you show us how it would look in its entirety under your proposal?

I think the proposal is for two things:

1. `async yield i` to be syntactic sugar for `yield i; await
asyncio.sleep(delay)`.

2. The interpreter should infer that a plain `def` function is actually
an `async def` from the presence of `async yield`, similar to the way
the interpreter infers that a plain `def` function is actually a
generator from the presence of a `yield`.


    # Original
    async def ticker(delay, to):
        """Yield numbers from 0 to to every delay seconds."""
        for i in range(to):
            yield i
            await asyncio.sleep(delay)


    # Re-written
    def ticker(delay, to):
        """Yield numbers from 0 to to every delay seconds."""
        for i in range(to):
            async yield i


So you save one line and perhaps 25-30 key presses when writing the
function, at the cost of making it much less clear what's going on when
reading the function.

How does it known how long to sleep?

What if you're not using asyncio, but some other framework?



--
Steven
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KKAAH3S4LM52NL5572LAY5QMHYUUUN7T/
Code of Conduct: http://python.org/psf/codeofconduct/



Hi Steven,

 

yes exactly I would like this.

 

Regarding the waiting and frameworks:

The solution should be independent from waiting and frameworks:

 

Let's see what happens now (sync, not async)

 

User has a generator, he wants values.

 

Uses a for cycle to process all values from generator:

Asks for first value - wait for the value to be computed

Processes the value he got

Asks for next value - wait for the value to be computed

And processes again, and again

 

 

The async version:

 

User has a generator, he wants values, he created an async version, because he wants the values faster

 

Uses a for cycle to process all values from generator:

Asks for first value - wait for the value to be computed

Processes the value he got - in the meantime, in the background the computation of next value is in progress

Asks for next value - it is possible that the values is already computed so there is only maximum a smaller wait for the value

And processes again, and again

 

 

So my idea above the syntax is the following:

When one value is yielded, the async generator starts computing in the background, it means it has to execute commands until next yield is reached (the next yield can be same one in a cycle or even a different yield statement .)

And stops when reaches the next yield.

 

When the next request comes for the next value, it gives the computed value if it is ready, or computes until the value is ready. And gives the value that time.

 

 

Actually I can imagine Python as being more and more async to be faster.

 

And therefore async could be the default working method.

 

Practically the user is not interested in how the value is computed, he just wants faster programs.

The only exception when async can be bad is when the computation of next value and processing the got value requires the same resource.

 

So when the default is async, the user will get faster program, by default. And he should only sign whe he does not want async, because of same resource usage.

 

 

BR,

__george__