Re: [Python-ideas] async objects

The problem is that if your goal is to make a practical proposal, it's not enough to look at Python-the-language. You're absolutely right, AFAICT there's nothing stopping someone from making a nice implementation of Python-the-language that has erlang-style cheap shared-nothing threads with some

Re: [Python-ideas] async objects

On 7 October 2016 at 16:42, Nathaniel Smith wrote: > For folks who prefer the > gevent API, is it really easier to port libraries to asyncio than to > port them to gevent? It's definitely *not* easier, as gevent lets you suspend execution inside arbitrary CPython magic method

Re: [Python-ideas] async objects

On Thu, Oct 6, 2016 at 4:12 PM, Greg Ewing wrote: > Nathaniel Smith wrote: >> >> The core distinguishing feature between >> async/await and gevent is the visibility of suspension points, so it >> might as well be the case that async/await is designed for exactly >>

Re: [Python-ideas] async objects

Yury Selivanov wrote: To start, no matter how exactly you want to approach this, it would require us to do a *complete rewrite* of CPython internals. This is so complex that we wouldn't be able to even estimate how long it would take us. You could ask the author of Stackless -- he did

Re: [Python-ideas] async objects

Nick Coghlan wrote: When a language usage pattern is supported for that long, but folks still don't grok how it might benefit them, you have a UX problem, and one of the ways to address it is to take the existing pattern and give it dedicated syntax, which is exactly what PEP 492 did. However,

Re: [Python-ideas] async objects

Nathaniel Smith wrote: The core distinguishing feature between async/await and gevent is the visibility of suspension points, so it might as well be the case that async/await is designed for exactly those people who want visible suspension points. They're not quite independent axes, though.

Re: [Python-ideas] async objects

On 6 October 2016 at 15:15, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > > Python's core runtime model is the C runtime model: threads (with a > > local stack and access to a global process heap) and processes (which > > contain a heap and one or

Re: [Python-ideas] async objects

On 6 October 2016 at 05:20, Sven R. Kunze 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

Re: [Python-ideas] async objects

On Thu, Oct 6, 2016 at 12:45 AM, Greg Ewing wrote: > Nathaniel Smith wrote: >> >> It wasn't that we created these keywords to solve some >> implementation problem and then inflicted them on users. > > > I disagree -- looking at the history of how we > ended up with

Re: [Python-ideas] async objects

Nathaniel Smith wrote: It wasn't that we created these keywords to solve some implementation problem and then inflicted them on users. I disagree -- looking at the history of how we ended up with async/await, it looks to me like this is exactly what *did* happen. First we had generators. Then

Re: [Python-ideas] async objects

> On 06 Oct 2016, at 07:15, Stephen J. Turnbull > wrote: > > Nick Coghlan writes: > >> Python's core runtime model is the C runtime model: threads (with a >> local stack and access to a global process heap) and processes (which >> contain a heap and one or

Re: [Python-ideas] async objects

Paul Moore wrote: I don't know *that* much about Erlang, but Python's model is that of a single shared address space with (potentially multiple) threads of code running, having access to that address space. I don't know much about Erlang either, but from what I gather, it's a functional

Re: [Python-ideas] async objects

On 5 October 2016 at 21:28, Rene Nejsum wrote: > But, are the runtimes for Python and Erlang that fundamentally different? Is > it Python’s tight integration with C that is the big difference? I don't know *that* much about Erlang, but Python's model is that of a single

Re: [Python-ideas] async objects

> On 05 Oct 2016, at 21:20, Sven R. Kunze 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

Re: [Python-ideas] async objects

On 10/05/2016 12:20 PM, Sven R. Kunze wrote: On 05.10.2016 18:06, Nick Coghlan wrote: 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

Re: [Python-ideas] async objects

On 05.10.2016 20:23, Michel Desmoulin wrote: On the other hand, await / async is a fantastic interface to unify all concurrent paradigms and asyncio already provide a bridge with threads and subprocess. So it kinda make sense. Almost if it would not require duplicate pieces of code. But

Re: [Python-ideas] async objects

On 05.10.2016 08:49, Rene Nejsum wrote: 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

Re: [Python-ideas] async objects

On the other hand, await / async is a fantastic interface to unify all concurrent paradigms and asyncio already provide a bridge with threads and subprocess. So it kinda make sense. Le 04/10/2016 à 18:40, Sven R. Kunze a écrit : On 04.10.2016 13:30, Nick Coghlan wrote: What it *doesn't* do,

Re: [Python-ideas] async objects

On 5 October 2016 at 16:49, Rene Nejsum wrote: >> On 04 Oct 2016, at 18:40, Sven R. Kunze wrote: >> 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 >>

Re: [Python-ideas] async objects

On Wed, Oct 5, 2016 at 3:40 AM, Sven R. Kunze wrote: > 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 >

Re: [Python-ideas] async objects

On 04.10.2016 13:30, Nick Coghlan wrote: What it *doesn't* do, and what you need greenlet for, is making that common interface look like you're using plain old synchronous C threads. If folks really want to do that, that's fine - they just need to add gevent/greenlet as a dependency, just as

Re: [Python-ideas] async objects

On Mon, Oct 3, 2016 at 10:37 PM, Rene Nejsum wrote: > Ideally I think a language (would love it to be Python) should > permit many (millions) of what we know as coroutines and then have as many > threads as the CPU have cores to execute this coroutines, but I do not thing > you

Re: [Python-ideas] async objects

Nick Coghlan writes: > What's not well-defined are the interfaces for calling into > asynchronous code from synchronous code. I don't understand the relevance to the content of the thread. As I understand the main point, Sven and Rene don't believe that [the kind of] async code [they want to

Re: [Python-ideas] async objects

> On 04 Oct 2016, at 07:26, Chris Angelico wrote: > > On Tue, Oct 4, 2016 at 4:25 PM, Rene Nejsum wrote: >>> On 04 Oct 2016, at 02:09, Stephen J. Turnbull >>> wrote: >>> >>> Rene Nejsum writes: I believe that you

Re: [Python-ideas] async objects

> On 03 Oct 2016, at 23:32, Greg Ewing wrote: > > 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. > >

Re: [Python-ideas] async objects

On 4 October 2016 at 10:48, C Anthony Risinger wrote: > In Go I can spawn a new control state (goroutine) at any time against any > function. This is clear in the code. In Erlang I can spawn a new control > state (Erlang process) at any time and it's also clear. Erlang is a

Re: [Python-ideas] async objects

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. Another thing is that async/await tasks are very lightweight compared to OS threads, so you can

Re: [Python-ideas] async objects

On Oct 3, 2016 7:09 PM, "Stephen J. Turnbull" < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > Rene Nejsum writes: > > > I believe that you should be able to code concurrent code, without > > being to explicit about it, but let the runtime handle low-level > > timing, as long as you know your

Re: [Python-ideas] async objects

Rene Nejsum writes: > I believe that you should be able to code concurrent code, without > being to explicit about it, but let the runtime handle low-level > timing, as long as you know your code will execute in the intended > order. Isn't "concurrent code whose order of execution you know"

Re: [Python-ideas] async objects

Hi Yann/ > On 03 Oct 2016, at 17: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

Re: [Python-ideas] async objects

On 3 October 2016 at 15:52, Giampaolo Rodola' wrote: > Independently from what the proposed solution is, I think you raised a very > valid concern: the DRY principle. > Right now the stdlib has tons of client network libraries which do not > support the new async model. > As

Re: [Python-ideas] async objects

Independently from what the proposed solution is, I think you raised a very valid concern: the DRY principle. Right now the stdlib has tons of client network libraries which do not support the new async model. As such, library vendors will have to rewrite them by using the new syntax and provide