3 ms·

At first look I don't like this. "async def" feels ugly, and I am not sure this is just because of the unfamiliarity. I don't believe coroutines/async routines

At first look I don't like this. "async def" feels ugly, and I am not sure this is just because of the unfamiliarity. I don't believe coroutines/async routines will ever be practical without decorators, so you might as well keep them and not disturb one of the most basic syntax rules of Python.

1st1 11y ago
> I don't believe coroutines/async routines will ever be practical without decorators Why do you believe so? Have you seen the implementation of asyncio.coroutine? Have you read the PEP thoroughly and saw the downsides of using a decorator/generators?
- RickHull 11y ago
  For those of us haven't, can you make the downsides clear? (links or text reply would be fantastic)
  - 1st1 11y ago
    Please read the Rationale of the PEP. edit: I can't explain topics better than I did so in the rationale section of the PEP. If I could, I would have explained it better in that section in the first place ;) As for asyncio.coroutine decorator -- it's just a very simple wrapper, that makes sure that the decorated object is a generator-function. If it's not -- it wraps it in one. It also does some magic to enable debug features. But with some serious shortcomings (that is also explained in the PEP in great detail). My point is: there is absolutely no other value in that decorator. There is nothing fundamental that it does, it just fixes the warts. Documentation, tooling, "easier to spot", etc arguments are unfortunately weak. The PEP makes coroutines in python a first-class language concept, with all the benefits you can have from it (better support in IDEs, tooling, sphinx, less questions on StackOverflow). Disclaimer: I'm the PEP author. I'm also python core developer, and I contributed to asyncio a lot.
- bayesianhorse 11y ago
  The major benefit I see to the decorator syntax is that there is not an extra distinction about functions. So currently we may have normal functions and generator functions. The latter are mostly functions which just return an iterator. Do we have to make a second distinction? Most of this is just "feeling". But good Python makes me feel good, so I sort of expect that from new features if I am to vote them up. I might like "codef" more than "async def", if there absolutely have to be first-class coroutines.

1st1 11y ago

> I don't believe coroutines/async routines will ever be practical without decorators Why do you believe so? Have you seen the implementation of asyncio.coroutine? Have you read the PEP thoroughly and saw the downsides of using a decorator/generators?

RickHull 11y ago
For those of us haven't, can you make the downsides clear? (links or text reply would be fantastic)
- 1st1 11y ago
  Please read the Rationale of the PEP. edit: I can't explain topics better than I did so in the rationale section of the PEP. If I could, I would have explained it better in that section in the first place ;) As for asyncio.coroutine decorator -- it's just a very simple wrapper, that makes sure that the decorated object is a generator-function. If it's not -- it wraps it in one. It also does some magic to enable debug features. But with some serious shortcomings (that is also explained in the PEP in great detail). My point is: there is absolutely no other value in that decorator. There is nothing fundamental that it does, it just fixes the warts. Documentation, tooling, "easier to spot", etc arguments are unfortunately weak. The PEP makes coroutines in python a first-class language concept, with all the benefits you can have from it (better support in IDEs, tooling, sphinx, less questions on StackOverflow). Disclaimer: I'm the PEP author. I'm also python core developer, and I contributed to asyncio a lot.
bayesianhorse 11y ago
The major benefit I see to the decorator syntax is that there is not an extra distinction about functions. So currently we may have normal functions and generator functions. The latter are mostly functions which just return an iterator. Do we have to make a second distinction? Most of this is just "feeling". But good Python makes me feel good, so I sort of expect that from new features if I am to vote them up. I might like "codef" more than "async def", if there absolutely have to be first-class coroutines.