On 7 July 2015 at 06:08, Sven R. Kunze wrote:
> I would like to rewrite/amend it to work asynchronously with minimal effort
> such as:
>
> def business_new():
> content1 = fork open('big.file').read() # wraps up the calls into
> awaitables
> content2 = fork open('huge.file').read() # and
On 06.07.2015 03:41, Nick Coghlan wrote:
That said, I think there's definitely value in providing a very simple
answer to the "how do I make a blocking call from a coroutine?"
question, so I filed an RFE to add asyncio.blocking_call:
http://bugs.python.org/issue24571
Nice step forward, Nick. Th
On 6 July 2015 at 10:49, Steven D'Aprano wrote:
> On Sun, Jul 05, 2015 at 11:50:00PM +0200, Sven R. Kunze wrote:
>
>> Seems like we stick to this example once again. So, let me get this
>> straight:
>>
>> 1) I can add, subtract, multiply and divide real numbers.
>> 2) I can add, subtract, multiply
other language that implemented this exact model a few years ago and it
works well.
Cheers,
Steve
Top-posted from my Windows Phone
From: Sven R. Kunze<mailto:srku...@mail.de>
Sent: 7/5/2015 14:50
To: python-dev@python.org<mailto:python-dev@python.o
On 6 July 2015 at 10:27, Chris Angelico wrote:
> On Mon, Jul 6, 2015 at 7:50 AM, Sven R. Kunze wrote:
>> Seems like we stick to this example once again. So, let me get this
>> straight:
>>
>> 1) I can add, subtract, multiply and divide real numbers.
>> 2) I can add, subtract, multiply and divide
On Sun, Jul 05, 2015 at 11:50:00PM +0200, Sven R. Kunze wrote:
> Seems like we stick to this example once again. So, let me get this
> straight:
>
> 1) I can add, subtract, multiply and divide real numbers.
> 2) I can add, subtract, multiply and divide complex numbers.
I don't think that this i
On Mon, Jul 6, 2015 at 7:50 AM, Sven R. Kunze wrote:
> Seems like we stick to this example once again. So, let me get this
> straight:
>
> 1) I can add, subtract, multiply and divide real numbers.
> 2) I can add, subtract, multiply and divide complex numbers.
> 3) I can even add, subtract, multipl
Thanks, Nick, for you reasoned response.
On 03.07.2015 11:40, Nick Coghlan wrote:
On 3 July 2015 at 06:55, Sven R. Kunze wrote:
My understanding of coloring is "needs special treatment".
Being special or not (containing an 'await' or not), as long as I don't need
to care, I can call them eith
On 3 July 2015 at 06:55, Sven R. Kunze wrote:
> My understanding of coloring is "needs special treatment".
>
> Being special or not (containing an 'await' or not), as long as I don't need
> to care, I can call them either way (with 'await' or not) and each case
> works sensibly that's fine with me
My understanding of coloring is "needs special treatment".
Being special or not (containing an 'await' or not), as long as I don't
need to care, I can call them either way (with 'await' or not) and each
case works sensibly that's fine with me.
Sensible would be something similar to:
call fun
Sven R. Kunze wrote:
I like the 'await' syntax to mark suspension points. But the 'async'
coloring makes no sense to me. It is an implementation details of
asyncio (IMHO).
Functions containing an "await" are going to be coloured
in any case -- that's unavoidable, given that await is
built on t
Hi,
I have never said I wanted implicit asyncio. Explicit is the Python way
after all, it served me well and I stick to that.
I like the 'await' syntax to mark suspension points. But the 'async'
coloring makes no sense to me. It is an implementation details of
asyncio (IMHO).
From what I
On Fri Jun 26 16:51:13 CEST 2015, Paul Sokolovsky wrote:
> So, currently in Python you know if you do:
>socket.write(buf)
> Then you know it will finish without interruptions for entire buffer.
How do you know that?
Are you assuming that socket.write is a builtin, rather than a
python me
On 27 June 2015 at 04:06, Ron Adam wrote:
> It seems that those points are defined by other means outside of a function
> defined with "async def". From the PEP...
>
>* It is a SyntaxError to have yield or yield from expressions
> in an async function.
>
> So somewhere in an async functi
Ethan Furman wrote:
> On 06/26/2015 08:47 AM, Steve Dower wrote:
>> On 06/26/2015 06:48 AM, Sven R. Kunze wrote:
>>
>>> def business():
>>> return complex_calc(5)
>>>
>>> def business_new()
>>> return await complex_calc(10)
>
>> Assuming "async def business_new" (to avoid the syntax error), there'
On 2015-06-26 1:40 PM, Ethan Furman wrote:
On 06/26/2015 08:47 AM, Steve Dower wrote:
On 06/26/2015 06:48 AM, Sven R. Kunze wrote:
def business():
return complex_calc(5)
def business_new()
return await complex_calc(10)
Assuming "async def business_new" (to avoid the syntax err
On 06/26/2015 10:31 AM, Chris Angelico wrote:
Apologies if this is a really REALLY dumb question, but... How hard
would it be to then dispense with the await keyword, and simply
_always_ behave that way? Something like:
def data_from_socket():
# Other tasks may run while we wait for data
On 06/26/2015 08:47 AM, Steve Dower wrote:
On 06/26/2015 06:48 AM, Sven R. Kunze wrote:
def business():
return complex_calc(5)
def business_new()
return await complex_calc(10)
Assuming "async def business_new" (to avoid the syntax error), there's no
difference between those fun
On 27 June 2015 at 00:31, Chris Angelico wrote:
> I come from a background of thinking with threads, so I'm accustomed
> to doing blocking I/O and assuming/expecting that other threads will
> carry on while we wait. If asynchronous I/O can be made that
> convenient, it'd be awesome.
Folks, it's w
On 06/26/2015 06:48 AM, Sven R. Kunze wrote:
> def business():
> return complex_calc(5)
>
> def business_new()
> return await complex_calc(10)
> Maybe, I completely missed the point of the proposal, but this is the way I
> would expect it to work. Putting in an 'await' whenever I see f
On 26 June 2015 at 23:48, Sven R. Kunze wrote:
> @Nick
> Thanks for these links; nice reads and reflect exactly what I think about
> these topics. Btw. complex numbers basically works the same way (same API)
> as integers.
Not using complex numbers in Python - coming to grips with what they
mean
On Sat, Jun 27, 2015 at 2:07 AM, R. David Murray wrote:
> On Sat, 27 Jun 2015 01:10:33 +1000, Chris Angelico wrote:
>> The way I'm seeing it, coroutines are like cooperatively-switched
>> threads; you don't have to worry about certain operations being
>> interrupted (particularly low-level ones l
On Sat, 27 Jun 2015 01:10:33 +1000, Chris Angelico wrote:
> The way I'm seeing it, coroutines are like cooperatively-switched
> threads; you don't have to worry about certain operations being
> interrupted (particularly low-level ones like refcount changes or list
> growth), but any time you hit a
On 2015-06-26 10:31 AM, Chris Angelico wrote:
On Sat, Jun 27, 2015 at 12:20 AM, Ethan Furman wrote:
>As Nick said earlier: the caller always blocks; by extension (to my mind, at
>least) putting an `await` in front of something is saying, "it's okay if
>other tasks run while I'm blocking on th
On Sat, Jun 27, 2015 at 12:51 AM, Paul Sokolovsky wrote:
> Some say "convenient", others say "dangerous".
>
> Consider:
>
> buf = bytearray(MULTIMEGABYTE)
>
> In one function you do:
>
> socket.write(buf),
>
> in another function (coroutine), you keep mutating buf.
>
> So, currently in Python you
Hello,
On Sat, 27 Jun 2015 00:31:01 +1000
Chris Angelico wrote:
> On Sat, Jun 27, 2015 at 12:20 AM, Ethan Furman
> wrote:
> > As Nick said earlier: the caller always blocks; by extension (to my
> > mind, at least) putting an `await` in front of something is saying,
> > "it's okay if other tasks
On Sat, Jun 27, 2015 at 12:20 AM, Ethan Furman wrote:
> As Nick said earlier: the caller always blocks; by extension (to my mind, at
> least) putting an `await` in front of something is saying, "it's okay if
> other tasks run while I'm blocking on this call."
Apologies if this is a really REALLY
On 06/26/2015 06:48 AM, Sven R. Kunze wrote:
def business():
return complex_calc(5)
def business_new()
return await complex_calc(10)
Maybe, I completely missed the point of the proposal, but this is the way I
would expect it to work. Putting in an 'await' whenever I see fit and it
On 25.06.2015 21:11, Andrew Svetlov wrote:
Another issue that bothers me, is code reuse. Independent from whether the
'async def' makes sense or not, it would not allow us to reuse asyncio
functions as if they were normal functions and vice versa (if I understood
that correctly). So, we would hav
On 26 Jun 2015 10:46, "Greg Ewing" wrote:
>
> Sven R. Kunze wrote:
>> So, we would have to implement things twice for the asyncio world and
the classic world.
>
>
> Not exactly; it's possible to create a wrapper that takes an
> async function and runs it to completion, allowing it to be
> called f
On 26 Jun 2015 05:15, "Andrew Svetlov" wrote:
>
> > Another issue that bothers me, is code reuse. Independent from whether
the
> > 'async def' makes sense or not, it would not allow us to reuse asyncio
> > functions as if they were normal functions and vice versa (if I
understood
> > that correctl
On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote:
>
> On 25.06.2015 04:16, Steven D'Aprano wrote:
> >On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
[...]
> >>What is the difference of a function (no awaits) or an awaitable (> 1
> >>awaits) from an end-user's perspectiv
Sven R. Kunze wrote:
# Call func syncronously, blocking until the calculation is done:
x = func()
# Call func asyncronously, without blocking:
y = await func()
Using the word "blocking" this way is potentially
confusing. The calling task is *always* blocked until
the operation completes. The
> Another issue that bothers me, is code reuse. Independent from whether the
> 'async def' makes sense or not, it would not allow us to reuse asyncio
> functions as if they were normal functions and vice versa (if I understood
> that correctly). So, we would have to implement things twice for the a
On 25.06.2015 04:16, Steven D'Aprano wrote:
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
Thanks, Yury, for you quick response.
On 24.06.2015 22:16, Yury Selivanov wrote:
Sven, if we don't have 'async def', and instead say that "a function
is a *coroutine function* when it ha
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
> Thanks, Yury, for you quick response.
>
> On 24.06.2015 22:16, Yury Selivanov wrote:
> >Sven, if we don't have 'async def', and instead say that "a function
> >is a *coroutine function* when it has at least one 'await'
> >expressio
Thanks, Yury, for you quick response.
On 24.06.2015 22:16, Yury Selivanov wrote:
Sven, if we don't have 'async def', and instead say that "a function
is a *coroutine function* when it has at least one 'await'
expression", then when you refactor "useful()" by removing the "await"
from it, it st
Hi Sven,
On 2015-06-24 2:14 PM, Sven R. Kunze wrote:
Hi everybody,
recently, I stumbled over the new 3.5 release and in doing so over PEP
0492.
After careful consideration and after reading many blog posts of
various coders, I first would like to thank Yury Selivanov and
everybody else who
Hi everybody,
recently, I stumbled over the new 3.5 release and in doing so over PEP 0492.
After careful consideration and after reading many blog posts of various
coders, I first would like to thank Yury Selivanov and everybody else
who brought PEP 0492 to its final state. I therefore conside
39 matches
Mail list logo
