classification
Title: Add CoroutineReturn and CoroutineExit builtin exceptions for coroutines
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: yselivanov Nosy List: gvanrossum, ncoghlan, scoder, yselivanov
Priority: normal Keywords:

Created on 2015-07-23 15:10 by yselivanov, last changed 2016-10-05 23:48 by yselivanov. This issue is now closed.

Messages (8)
msg247214 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-07-23 15:10
Since native coroutines (see PEP 492) hadn't had a separate type when the PEP was accepted, we didn't discuss that it might be necessary to introduce new exception types specifically for coroutines.

To maintain backwards compatibility with 3.5, I think we can do the following:

1. Add CoroutineReturn exception type, inherited from StopIteration;

2. Add CoroutineExit exception type, inherited from GeneratorExit.
msg247217 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-07-23 15:33
What problem does this solve?
msg247218 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-07-23 15:33
What problem does this solve?
msg247227 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2015-07-23 18:28
> What problem does this solve?

Only avoiding confusion, because coroutines now have a separate type, lack __iter__, and thus are quite different (on the surface) from generators. The fact that 'coro.send(..)' raises StopIteration (when coroutines aren't iterable), and that 'coro.close()' raises GeneratorExit might be confusing and non-obvious to some users.

FWIW I created this ticket mostly as a reminder for myself to have some discussion on this topic in the future, when 3.5 is released and we have some initial feedback on PEP 492 ideas.
msg247229 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2015-07-23 19:53
Hm, I think there's little need for new exceptions...
msg247230 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2015-07-23 20:27
> Hm, I think there's little need for new exceptions...

While I agree with Yuri that the names are a bit awkward, I actually second this. The StopIteration is almost an implementation detail of how the return value is passed on to become the (Future) result of the coroutine. It is intended to be caught by some framework and users would not normally get to see that exception. There is little room for general confusion.
msg247263 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2015-07-24 08:35
My initial inclination is to agree with Stefan. At the moment, we have a
slightly leaky abstraction where the exceptions used mean that coroutines
still expose the fact that under the covers they're defined in terms of
generator semantics.

However, that leak in the abstraction reveals an underlying truth -
coroutine semantics *are* derived from generator semantics, and they *do*
share common underlying infrastructure.

We may eventually find pragmatic reasons for wanting to plug that leak and
use separately named exceptions, but unlike the situation with coroutines
themselves, I'm not currently seeing a clear gain in either usability or
comprehensibility as a payoff for the extra complexity.
msg278164 - (view) Author: Yury Selivanov (yselivanov) * (Python committer) Date: 2016-10-05 23:48
Closing this one. Seems we can live just fine without these new exceptions.
History
Date User Action Args
2016-10-05 23:48:17yselivanovsetstatus: open -> closed
resolution: wont fix
messages: + msg278164

stage: resolved
2015-07-24 08:35:13ncoghlansetmessages: + msg247263
2015-07-23 20:27:26scodersetnosy: + scoder
messages: + msg247230
2015-07-23 19:53:18gvanrossumsetmessages: + msg247229
2015-07-23 18:28:10yselivanovsetmessages: + msg247227
2015-07-23 15:33:26gvanrossumsetmessages: + msg247218
2015-07-23 15:33:23gvanrossumsetmessages: + msg247217
2015-07-23 15:10:15yselivanovcreate