[Python-ideas] [asyncio] Suggestion for a major PEP

[Christophe Bailly]

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 at 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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181216/d84c2005/attachment-0001.html>