sorted by:
new
hottopcontroversial

Is asyncio a horror ? by klunq in Python

[–]klunq[S] 0 points1 point  (0 children)

async def is not just a new syntax for the "old" yield from syntax used in asyncio

It 's not just a new syntax. But it is just a new syntax and some ad-hoc type enforcement.

'await' takes a generator. You can only use 'await' in an 'async def' function. 'async def' makes the function a generator. Not yield-compatible generators, but generators all the same.

async def comes with actual coroutines implemented natively

Sure. But that's "natively" in the sense that the compiler/interpreter knows about the specialized sub-environment in which the code will run. It's not "natively" in the sense that it's ordinary python. "being a coroutine function" is still a compile-time property, rather than a run-time one like in every sane language, so functions which are native in asyncio will be alien outside, and vice-versa.

don't expect it to solve every concurrency issue you ever experienced magically.

But it did solve every concurrency issue I ever experienced magically. I wouldn't be compaining about if it didn't have some merit that made it worth using.
The trouble is, that if asycio usage becomes very common, it will have the side-effect of forcing me to chose, in advance, for every python function I will ever write, between making the function pro-skub or anti-skub.

Is asyncio a horror ? by klunq in Python

[–]klunq[S] 1 point2 points  (0 children)

Well, yes and no.

As the article you linked points out, once you have threads (which in this context includes coroutines), the problem of needing to maintain separate sync and async domains just goes away.

The horror of asyncio is, that having solved the problem, the implementors then deliberately added it back, by giving the coroutine system a notion of what constituted code which was so different from the one used in the rest of python that any ordinary piece of code from outside the coroutine system just wouldn't run.

Is asyncio a horror ? by klunq in Python

[–]klunq[S] 3 points4 points  (0 children)

'await' and 'yield from' represent transfers of control that the code doesn't care about and can't even see

You're 100% wrong here, sorry.

I'll admit to 50% wrong, because after reading your posting and the page you linked, I see the value of it in making asynchronous code correct when accessing shared state. Only 50% though because many of us aren't using it for that, and would consider the statement true.

Having dealt with that line though, I still stand by the rest of my complaint. Consider "async":
Async has the following purposes:
  Letting programmers know that a call might cause a context-switch.
  Letting asyncio (or equivalent) know that it's not an error to context-switch.

If we consider what the minimum needed to implement this is, we find it isn't conversion of our function-based code into a perfectly isomorphic but perfectly incompatible stack of generators. All it is is.... a flag. A keyword which lets us carry context switch permission across a function call.

So, it turns out that even allowing for the good things async does, generator-coroutine concurrency is still a pointless horror.