Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #89106 > unrolled thread

PEP 492, new coroutine syntax for Python

Back to article view | Back to comp.lang.python

Contents

  PEP 492, new coroutine syntax for Python Paul Rubin <no.email@nospam.invalid> - 2015-04-17 20:47 -0700
    Re: PEP 492, new coroutine syntax for Python Chris Angelico <rosuav@gmail.com> - 2015-04-18 14:02 +1000
      Re: PEP 492, new coroutine syntax for Python Paul Rubin <no.email@nospam.invalid> - 2015-04-17 22:32 -0700
        Re: PEP 492, new coroutine syntax for Python Chris Angelico <rosuav@gmail.com> - 2015-04-18 16:20 +1000
      Re: PEP 492, new coroutine syntax for Python Marko Rauhamaa <marko@pacujo.net> - 2015-04-18 10:35 +0300

#89106 — PEP 492, new coroutine syntax for Python

I don't remember anyone mentioning this here yet, and it is mighty cool:

https://www.python.org/dev/peps/pep-0492/

[toc] | [next] | [standalone]

#89107

On Sat, Apr 18, 2015 at 1:47 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> I don't remember anyone mentioning this here yet, and it is mighty cool:
>
> https://www.python.org/dev/peps/pep-0492/

Hah. It only just hit python-ideas, so you're jumping in on something
brand new - no wonder it hasn't been mentioned yet :)

And yes, it IS cool. I think the current proposal has a lot of
duplication (it looks like there's almost a complete replica of the
generator protocol being created in parallel), but whatever happens,
it's a good thing.

The document's in a state of some flux at the moment. If you're
interested, I strongly recommend jumping over to python-ideas and
following along - that is, if you're interested enough to drink from
the veritable fire-hose of -ideas! There's a chance this will land in
Python 3.5, but if not, I'd be very surprised if it doesn't hit 3.6.
This is an exciting time to be a Python programmer!

ChrisA

[toc] | [prev] | [next] | [standalone]

#89110

Chris Angelico <rosuav@gmail.com> writes:
> Hah. It only just hit python-ideas, so you're jumping in on something
> brand new - no wonder it hasn't been mentioned yet :)

Interesting.  It's dated a couple weeks ago and has obviously been in
the works for a while.  There's a working implementation which I'd think
means it's outside the idea phase.

> I think the current proposal has a lot of duplication (it looks like
> there's almost a complete replica of the generator protocol being
> created in parallel), but whatever happens, it's a good thing.

But it's so much cleaner than the existing generator stuff and can
pretty much replace it.  That is the kind of change that Python 3 really
should have been about.

> I strongly recommend jumping over to python-ideas and following along
> - that is, if you're interested enough to drink from the veritable
> fire-hose of -ideas! 

I might take a look at the list archive.  I don't think I could deal
with actually receiving the mailings and trying to keep up with them.

> There's a chance this will land in Python 3.5, but if not, I'd be very
> surprised if it doesn't hit 3.6.  

Neat :).  This paper about Lua coroutines is good and if it hasn't been
part of the PEP discussion and looks relevant, you might want to post it
there:

http://www.jucs.org/jucs_10_7/coroutines_in_lua/de_Moura_A_L.pdf

[toc] | [prev] | [next] | [standalone]

#89111

On Sat, Apr 18, 2015 at 3:32 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> Hah. It only just hit python-ideas, so you're jumping in on something
>> brand new - no wonder it hasn't been mentioned yet :)
>
> Interesting.  It's dated a couple weeks ago and has obviously been in
> the works for a while.  There's a working implementation which I'd think
> means it's outside the idea phase.

I'm not sure, but I suspect it's been developed/discussed in a SIG.
Today's the first day I've seen stuff about it.

>> I think the current proposal has a lot of duplication (it looks like
>> there's almost a complete replica of the generator protocol being
>> created in parallel), but whatever happens, it's a good thing.
>
> But it's so much cleaner than the existing generator stuff and can
> pretty much replace it.  That is the kind of change that Python 3 really
> should have been about.

Generators have other uses, but I think the intention is to subsume
all the generator-based coroutine system. You'd have to raise this on
-ideas, though.

>> There's a chance this will land in Python 3.5, but if not, I'd be very
>> surprised if it doesn't hit 3.6.
>
> Neat :).  This paper about Lua coroutines is good and if it hasn't been
> part of the PEP discussion and looks relevant, you might want to post it
> there:
>
> http://www.jucs.org/jucs_10_7/coroutines_in_lua/de_Moura_A_L.pdf

I hate to say TLDR, but it's the truth here. I'm posting from theatre
(we're performing The Merry Widow and I'm checking in between follow
spot cues... yeah, I'm insane), and don't have time this week to
evaluate a paper like that on a subject that I'm not an expert on.
Either someone else who subscribes to both python-list and
python-ideas will post it, or you'll have to join -ideas yourself,
sorry.

ChrisA

[toc] | [prev] | [next] | [standalone]

#89116

Chris Angelico <rosuav@gmail.com>:

> On Sat, Apr 18, 2015 at 1:47 PM, Paul Rubin <no.email@nospam.invalid> wrote:
>> I don't remember anyone mentioning this here yet, and it is mighty cool:
>>
>> https://www.python.org/dev/peps/pep-0492/
>
> [...]
>
> And yes, it IS cool. I think the current proposal has a lot of
> duplication (it looks like there's almost a complete replica of the
> generator protocol being created in parallel), but whatever happens,
> it's a good thing.

I'm not sold on this coroutine fad. Deep down it's a rehash of the old
false promise of thread programming: you can write reactive, scalable
programs linearly.

Reactive systems are complex and messy. In my experience the mess is
managed most clearly when the participating state machines have a
prominent place in the program text. IOW, you should *highlight* states
with names that stick out. Threads and coroutines *downplay* states.

Threads and coroutines look neat when they expect only one kind of input
in any given state. At least coroutines (unlike threads) can be
interrupted from the outside. However, implementing a state with
multiple alternative stimuli easily results in lengthy, deeply-nested,
messy code.

To minimize the mess, what ends up happening is that you start one
peripheral coroutine (or thread) per input source and have it convert
the stimulus into method calls (callbacks). IOW, coroutines take the
role of interrupt handlers.

But then, I think that's a lot of conceptual and design machinery for
such a simple thing. Callback dispatching from select.epoll() achieves
the same objective.

Now, the PEP proposal text mentions asynchronous database calls as an
example. If coroutines are the price of asynchronizing database access,
maybe the price is worth the prize.


Marko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web