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
ACTIVITY SUMMARY (2015-06-19 - 2015-06-26)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4908 (+16)
closed 31369 (+27)
total 36277 (+43)
Open issues wit
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
20 matches
Mail list logo
