[Python-ideas] async objects

[Rene Nejsum]

> On 05 Oct 2016, at 21:20, Sven R. Kunze <srkunze at mail.de> wrote:
> 
> On 05.10.2016 18:06, Nick Coghlan wrote:
>> [runtime matters]
> 
> I think I understand your point.
> 
> I also hope that others and me could provide you with our perspective. We see Python not as a C-like runtime but as an abstract modelling language. I know that it's different from the point of view of CPython internals, however from the outside Python suggests to be much more than a simple wrapper around C. Just two different perspectives.

Excellent point. For me CPython, Jython, IronPython, PyPy are the same (99.9%) and the important part is the Python the language. For a long time I tested PYWORKS again all implementations and were happy that it ran on all. Clearly, for others CPython (incl. runtime and C-bindings) is the fact and the others are far from the same, especially because the missing C-integration.

But, are the runtimes for Python and Erlang that fundamentally different? Is it Python’s tight integration with C that is the big difference? 

When I first read about the async idea, I initially expected that it would be some stackless like additions to Python. My wish for Python was an addition to the language the allowed an easy an elegant concurrent model on the language level. Ideally a Python program with 1000 async objects parsing a 10TB XML in-memory file, should run twice as fast on a 8-core CPU, compared to  a 4-core ditto. 


> Unfortunately, your runtime explanations still don't address the DRY issue. :-/
> 
>> Guido's idea of a shadow thread to let synchronous threads run
>> coroutines without needing to actually run a foreground event loop
>> should provide a manageable way of getting the two runtime models
>> (traditional C and asynchronous coroutines) to play nicely together in
>> a single application, and has the virtue of being something folks can
>> readily experiment with for themselves before we commit to anything
>> specific in the standard library (since all the building blocks of
>> thread local storage, event loop management, and inter-thread message
>> passing primitives are already available).
> 
> I needed to think about this further when Guido mentioned it. But I like it now.
> 
> If you check https://github.com/srkunze/fork/tree/asyncio , I already started working on integrating asyncio into xfork at long time ago. But I still couldn't wrap my mind around it and it stalled. But IIRC, I would have implemented a shadow thread solution as well. So, if his idea goes into the stdlib first, I welcome it even more as it would do the heavy lifting for me. xfork would then be just a common interface to threads, processes and coroutines.

xfork (as pyworks) implements a proxy object, which “almost” behaves like the real object, but it is still a proxy. If fork (or spawn, chan, async, whatever.) was a part of the language it would be more clean.

br
/Rene


> 
> Cheers,
> Sven
>