> On 04 Oct 2016, at 18:40, Sven R. Kunze <srku...@mail.de> wrote: > > On 04.10.2016 09:50, Stephen J. Turnbull wrote: >> As I understand the main point, Sven and Rene don't believe that [the >> kind of] async code [they want to write] should need any keywords; >> just start the event loop and invoke functions, and that somehow >> automatically DTRTs. > [reading my name second time] > > > I don't think that's actually what I wanted here. One simple keyword should > have sufficed just like golang did. So, the developer gets a way to decide > whether or not he needs it blocking or nonblocking **when using a function**. > He doesn't need to decide it **when writing the function**.
I agree, that’s why i proposed to put the async keyword in when creating the object, saying in this instance I want asynchronous communication with the object. > You might wonder why this is relevant. DRY principle has been mentioned but > there's more to it. Only the caller **can decide** whether it needs to wait > or not. Why? Because, the caller works WITH the result of the called function > (whatever results means to you). The caller is (what Nick probably would > call) the orchestrator, as it has the knowledge about the relation and > interaction between domain-specific function calls. +1 > As a result of past discussions, I wrote the module "xfork" which basically > does this "golang goroutine" stuff. It's just a thin wrapper around "futures" > but it allows to avoid that what René and Anthony objects about. I had a look at xfork, and really like it. It is implemented much like the lower level of PYWORKS and PYWORKS could build on xfork instead. I think that the “model” of doing async should be defined in the Python language/runtime (like in Go, Erlang, ABCL) . I the ideal case it should be up to the runtime implementation (CPython, PyPy, Jython, IronPython etc.) how the asynchronous behaviour is implemented (greenlets, threads, roll-it-own, etc) br /Rene > > Cheers, > Sven > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
