Paul,
On 2015-04-26 8:17 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 19:45:30 -0400
Yury Selivanov wrote:
[]
Then, is the only logic for proposing __aenter__ is to reinsure
against a situation that someone starts to write async context
manager, forgets that they write async contex
Paul,
On 2015-04-26 7:32 PM, Paul Sokolovsky wrote:
Hello,
On Sun, 26 Apr 2015 18:49:43 -0400
Yury Selivanov wrote:
[]
- it would look confusing
Sorry, "async def __enter__" doesn't look more confusing than
"__aenter__" (vs "__enter__").
I'll update the PEP.
The argument shouldn't be tha
But new syntax is the whole point of the PEP. I want to be able to
*syntactically* tell where the suspension points are in coroutines.
Currently this means looking for yield [from]; PEP 492 just adds looking
for await and async [for|with]. Making await() a function defeats the
purpose because now a
Paul,
On 2015-04-26 6:25 PM, Paul Sokolovsky wrote:
Ok, so here're 3 points this link gives, with my concerns/questions:
>An alternative idea about new asynchronous iterators and context
>managers was to reuse existing magic methods, by adding an async
>keyword to their declarations:
>[But:]
>
On 27 Apr 2015 07:50, "Mark Shannon" wrote:
> On 26/04/15 21:40, Yury Selivanov wrote:
>>
>> But it's hard. Iterating through something asynchronously? Write a
>> 'while True' loop. Instead of 1 line you now have 5 or 6. Want to
>> commit your database transaction? Instead of 'async with' you
Brett,
On 2015-04-26 6:09 PM, Brett Cannon wrote:
How is it a burden for people porting Python 2 code? Because they won't
get to name anything 'async' just like anyone supporting older Python 3
versions? Otherwise I don't see how it is of any consequence to people
maintaining 2/3 code as it wi
On 2015-04-26 5:48 PM, Mark Shannon wrote:
On 26/04/15 21:40, Yury Selivanov wrote:
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
I did
On Sun, Apr 26, 2015, 17:49 Mark Shannon wrote:
On 26/04/15 21:40, Yury Selivanov wrote:
> Hi Mark,
>
> On 2015-04-26 4:21 PM, Mark Shannon wrote:
>> Hi,
>>
>> I was looking at PEP 492 and it seems to me that no new syntax is
>> required.
>
> Mark, all your points are explained in the PEP in a g
On 26/04/15 21:40, Yury Selivanov wrote:
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
I did read the PEP. I do think that clarifying the
Hi Mark,
On 2015-04-26 4:21 PM, Mark Shannon wrote:
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is
required.
Mark, all your points are explained in the PEP in a great detail:
Looking at the code, it does four things; all of which, or a
functional equivalent, could
How do you implement "async for"?
On Sun, Apr 26, 2015 at 11:21 PM, Mark Shannon wrote:
> Hi,
>
> I was looking at PEP 492 and it seems to me that no new syntax is required.
>
> Looking at the code, it does four things; all of which, or a functional
> equivalent, could be done with no new syntax
Hi,
I was looking at PEP 492 and it seems to me that no new syntax is required.
Looking at the code, it does four things; all of which, or a functional
equivalent, could be done with no new syntax.
1. Make a normal function into a generator or coroutine. This can be
done with a decorator.
2. S
Le 25 avr. 2015 23:02, "Yury Selivanov" a écrit :
> I agree. I plan to update the PEP with some new
> semantics (prohibit passing coroutine-objects to iter(),
> tuple() and other builtins, as well as using them in
> 'for .. in coro()' loops). I'll add a section with
> a more detailed explanation
13 matches
Mail list logo
