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 an

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 such, library vendors

Re: [Python-ideas] async objects

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 t

Re: [Python-ideas] async objects

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 prop

Re: [Python-ideas] if-statement in for-loop

Hi, On 11/09/16 10:36, Dominik Gresch wrote: So I asked myself if a syntax as follows would be possible: for i in range(10) if i != 5: body I've read the thread and I understand the general issues with making the condition part of the expression. However, what if this wasn't part of ch

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 readable through the use > o

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" a

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 c

Re: [Python-ideas] if-statement in for-loop

On 4 October 2016 at 08:18, Erik wrote: > The expression suggested could be spelled: > > for i in range(10): if i != 5: > body > > So, if a colon followed by another suite is equivalent to the same construct > but without the INDENT (and then the corresponding DEDENT unwinds up to the > point

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 a

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 little > different beca

Re: [Python-ideas] async objects

On Tue, Oct 4, 2016 at 8:32 AM, 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. > > > Another thing is that async/awa

Re: [Python-ideas] if-statement in for-loop

In my experience it is exceptions and inconsistencies that consume 'working memory in the brain of humans'. By eliminating the distinction between list comprehensions and for loops we would be making the language simpler by eliminating an inconsistency. Furthermore, I do not believe it is valid to

Re: [Python-ideas] async objects

> On 04 Oct 2016, at 02:09, Stephen J. Turnbull > 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 code will execute in the intended >> ord

Re: [Python-ideas] async objects

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 should be able to code concurrent code, without >>> being to explicit about it, but let the runtime handle low-level >>> timing, as long

Re: [Python-ideas] async objects

> On 04 Oct 2016, at 02:48, C Anthony Risinger wrote: > > On Oct 3, 2016 7:09 PM, "Stephen J. Turnbull" > > wrote: > > > > Rene Nejsum writes: > > > > > I believe that you should be able to code concurrent code, without > > > being to explicit abou