[Python-ideas] PEP 525: Asynchronous Generators

[Andrew Svetlov]

> Sure. So, what do you think about the separate attribute to make people
aware?

What people should be aware about?
IMHO sync generators and async ones have different types. What also is
needed?

On Mon, Aug 8, 2016 at 2:45 PM Sven R. Kunze <srkunze at mail.de> wrote:

> On 06.08.2016 01:25, Yury Selivanov wrote:
> >
> > On 2016-08-05 4:51 PM, Sven R. Kunze wrote:
> >> Yes, that is how I understand it as well. So, all this complexity
> >> stems from the intertwining of generators and coroutines.
> >>
> >> I am wondering if loosening the tie between the two could make it all
> >> simpler; even for you. (Not right now, but maybe later.)
> >
> > Unfortunately, the only way to "loosen the tie" is to re-implement
> > generator protocol for coroutines (make them a separate thing).
> > Besides breaking backwards compatibility with the existing Python code
> > that uses @coroutine decorator and 'yield from' syntax, it will also
> > introduce a ton of work.
>
> You are the best to know that. :)
>
> >>
> >> I think that is related to Stefan's question here. I cannot speak for
> >> him but it seems to me the confusion is actually the other way around.
> >>
> >> Coming from a database background, I prefer redundant-free data
> >> representation. The "a" prefix encodes the information "that's an
> >> asynchronous generator" which is repeated several times and thus is
> >> redundant.
> >>
> >> Another example: when writing code for generators and checking for
> >> the "send" method, I would then need to check for the "asend" method
> >> as well. So, I would need to touch that code although it even might
> >> not have been necessary in the first place.
> >>
> >> I don't want to talk you out of the "a" prefix, but I get the feeling
> >> that the information "that's asynchronous" should be provided as a
> >> separate attribute. I believe it would reduce confusion, simplify
> >> duck-typing and flatten the learning curve. :)
> >
> >
> > Thing is you can't write one piece of code that will accept any type
> > of generator (sync or async).
> >
> > * send, throw, close, __next__ methods for sync generators, they are
> > synchronous.
> >
> > * send, throw, close, __next__ methods for async generators, they
> > *require* to use 'await' on them.  There is no way to make them
> > "synchronous", because you have awaits in async generators.
>
> There are a lot of things you can do with generators (decorating, adding
> attributes etc.) and none of them require you to "make them synchronous".
>
> > Because of the above, duck-typing simply isn't possible.
>
> See above.
>
> > The prefix is there to make people aware that this is a completely
> > different API, even though it looks similar.
>
> Sure. So, what do you think about the separate attribute to make people
> aware?
>
>
> Best,
> Sven
> _______________________________________________
> 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/
>
-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160808/5fdcc952/attachment.html>