Hello,

Thanks for your answer.

The advantage of this method is that you still follow the logic of async/await. In fact you make it even easier,. It is just a different implementation but with fewer constraints.

So my suggestion is to keep this logic because it is a very good logic !!!. , But we should remove this unjusfied chaining of async/await methods.

To be clear, this is an async /await logic, except you have an async on one end and an await at the other end and you remove everything in between !

I could have written my examples with async/await, I have used the future syntax but it is the same. I can rewrite my examples if you prefer, I will just use other keywords.

That is my opinon, we differ on this but I think there is something really wrong when you add unjustified syntax.

You suggest gevent but where do you see async await in gevent ?

From my experience, this is really a pain to mix async code with sync code with the current implementation. Of course you can create threads instead but it is better and simpler to remain async if possible

I think there is a flaw in this logic, again this is my opinion, my main intention is to share ideas.

I perfectly understand that it is late to implement this, but we could take also into account the real limitations that are difficult to overcome with asyncio. I think I do not need to post links, many will undertand the constraints I am talking about.

Regards,

Chris

On Sun, 16 Dec 2018 at 10:16, Nathaniel Smith <njs@pobox.com> wrote:

If you want this style of concurrency, you don't need to write a PEP,
just 'pip install gevent' :-)

But unfortunately you're years too late to argue for making asyncio
work this way. This was discussed extensively at the time, and the
decision to use special syntax was made intentionally, and after
studying existing systems like gevent that made the other choice.

This section of the trio docs explain why explicit async/await syntax
makes life easier for developers:
https://trio.readthedocs.io/en/latest/reference-core.html#checkpoints

It's also awkward but very doable to support both sync and async mode
with a single code base: https://github.com/python-trio/unasync/

In fact, when doing this, the async/await syntax isn't really the hard
part – the hard part is that different libraries have very different
networking APIs. E.g., the stdlib socket API and the stdlib asyncio
API are totally different.

-n
On Sun, Dec 16, 2018 at 12:21 AM Christophe Bailly <chbailly@gmail.com> wrote:
>
> Hello,
>
> I copy paste the main idea from an article I have written:
> contextual async
>
> "
>
> Imagine you have some code written for monothread. And you want to include your code in a multithread environment. Do you need to adapt all your code which is what you do when you want to migrate to async code ? The answer is no.
>
> Functionnally these constraints are not justified neither technically
>
> Do we have the tools to do this ? Yes because thanks to boost::context we can switch context between tasks. When a task suspends, it just calls a function (the event loop or reactor) to potentially switch to another task. Just like threads switch contexts…
>
> Async/Await logic has introduced a symetric relation wich introduces unnecessary contraints. We should just the same logic as thread logic.
>
> "
>
> Read the examples in the article I have developped a prototype in C++ and everything works perfectly.
>
> My opinion is that sooner or later, it will have to switch to this logic because chaining async/aswait is a huge contraints and does not make sense in my opinion.
>
> Maybe I am missing something,
>
> Feel free to give me your feedback.
>
> Regards,
>
>
> Chris
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

--
Nathaniel J. Smith -- https://vorpus.org