On 2016-10-03 16:46, Yann Kaiser wrote:
The way I see it, the great thing about async/await as opposed to
threading is that it is explicit about when execution will "take a
break" from your function or resume into it. This is made clear and
readable through the use of `await` keywords.
Your proposal unfortunately goes directly against this idea of
explicitness. You won't know what function will need to be fed into an
event loop or not. You won't know where your code is going to lose or
gain control.
Could we turn this around the other way and allow the use of 'await' in
both cases, checking at runtime whether it needs to behave
asynchronously or not?
On Sun, Oct 2, 2016, 14:26 Rene Nejsum <r...@stranden.com
<mailto:r...@stranden.com>> wrote:
Having followed Yury Selivanov yselivanov.ml <http://yselivanov.ml>
at gmail.com <http://gmail.com> proposal to add async/await to
Python (PEP 492 Coroutines with async and await syntax and (PEP 525
Asynchronous Generators) and and especially the discussion about
PEP 530: Asynchronous Comprehensions I would like to add some
concerns about the direction Python is taking on this.
As Sven R. Kunze srkunze at mail.de <http://mail.de> mentions the is
a risk of having to double a lot of methods/functions to have an
Async implementation. Just look at the mess in .NET when Microsoft
introduced async/await in their library, a huge number of functions
had to be implemented with a Async version of each member.
Definitely not the DRY principle.
While I think parallelism and concurrency are very important
features in a language, I feel the direction Python is taking right
now is getting to complicated, being difficult to understand and
implement correct.
I thought it might be worth to look at using async at a higher
level. Instead of making methods, generators and lists async, why
not make the object itself async? Meaning that the method call
(message to object) is async
Example:
class SomeClass(object):
def some_method(self):
return 42
o = async SomeClass() # Indicating that the user want’s an async
version of the object
r = o.some_method() # Will implicit be a async/await “wrapped”
method no matter impl.
# Here other code could execute, until the result (r) is referenced
print r
I think above code is easier to implement, use and understand, while
it handles some of the use cases handled by defining a lot of
methods as async/await.
I have made a small implementation called PYWORKS
(https://github.com/pylots/pyworks), somewhat based on the idea
above. PYWORKS has been used in several real world implementation
and seams to be fairly easy for developers to understand and use.
br
/Rene
PS. This is my first post to python-ideas, please be gentle :-)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
