add coroutine behavior for generators #3178
Conversation
|
What do you think about async only being enabled on non-m0? |
I could imagine async being used for simple multi-task timing projects even on a Trinket M0, say. I think a simple task library would fit. Is the problem with the bast pro mini that it has more pins than other small boards like trinket and gemma? |
|
While looking at #3190, I realized that both |
Sure, but that doesn't mean we need it enabled. There are lots of things that could be useful on an M0.
Yes, I think so.
Nice! That'll do. How much do we gain with |
I was just thinking that if it was really easy to use, it could be used in simple blinky and NeoPixel programs, etc.
Well, that's weird:
|
Async is useful everywhere; right now it's nowhere. There's no great loss if it's not available on m0 at the outset. It might be a problem in the future, as it's a core language feature, but on the short-to-medium term it seems fine. Right now I'm happy to disable any target that does not easily build (given that there is a pretty healthy crop of boards that do build). If there is demand on those tiny boards the problems can be solved. |
coroutines don't have __next__; they also call themselves coroutines. This does not change the fact that `async def` methods are generators, but it does make them behave more like CPython.
a6322ed to
e9b4e0b
Compare
|
Let's try a rebase and see what shakes loose |
|
@tannewt okay, this passes after a rebase so the can is kicked one commit further down the road. |
coroutines don't have next; they also call themselves coroutines.
This does not change the fact that
async defmethods are generators,but it does make them behave more like CPython.
This also turns on
asyncin mpy-cross so tests will pass, though the exception thrown by the mpy-cross byte code is not very helpful.