On 25 April 2015 at 22:02, Yury Selivanov wrote:
[...]
> On 2015-04-25 4:47 PM, Arnaud Delobelle wrote:
[...]
>> 1. About the 'async for' construct. Each iteration will create a new
>> coroutine object (the one returned by Cursor.__anext__()) and it seems
>> to me that it can be wasteful. In th
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
Hi Arnaud,
On 2015-04-25 4:47 PM, Arnaud Delobelle wrote:
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote:
Hi python-dev,
I'm moving the discussion from python-ideas to here.
The updated version of the PEP should be available shortly
at https://www.python.org/dev/peps/pep-0492
and is also
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote:
>
> Hi python-dev,
>
> I'm moving the discussion from python-ideas to here.
>
> The updated version of the PEP should be available shortly
> at https://www.python.org/dev/peps/pep-0492
> and is also pasted in this email.
>
Hi Yury,
Having read t
I used to think in the same way but found the result looks like Perl
(or Haskell), not Python.
On Sat, Apr 25, 2015 at 7:47 AM, Greg Ewing wrote:
> Wild idea:
>
> Let "@" mean "async" when it's directly in front
> of a keyword.
>
> Then we would have:
>
> @def f():
> ...
>
> @for x in it
Wild idea:
Let "@" mean "async" when it's directly in front
of a keyword.
Then we would have:
@def f():
...
@for x in iter:
...
@with context as thing:
...
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
Hello,
On Fri, 24 Apr 2015 12:04:27 -0700
Łukasz Langa wrote:
[]
> >
> > They would likely search for something like
> > r"^\s*def\s+[a-zA-Z0-9_]+" which will hit "def async spam" but not
> > "async def”.
>
> Realistically that can’t be what they’re doing because of multiple
> string literals,
> On Apr 24, 2015, at 6:32 AM, Barry Warsaw wrote:
>
> On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
>
>> It seems to me that tools that search for r"^\s*def\s+spam\s*\(" are
>
> They would likely search for something like r"^\s*def\s+[a-zA-Z0-9_]+" which
> will hit "def async spam" but
On Fri, Apr 24, 2015 at 09:32:51AM -0400, Barry Warsaw wrote:
> On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
>
> >It seems to me that tools that search for r"^\s*def\s+spam\s*\(" are
>
> They would likely search for something like r"^\s*def\s+[a-zA-Z0-9_]+" which
> will hit "def async spa
On Apr 24, 2015, at 08:03 PM, Greg Ewing wrote:
>Putting it at the end would seem least likely to
>cause breakage:
>
>def useful() async:
That's not bad IMHO. I wonder how crazy it is in the face of, ahem, function
annotations.
Cheers,
-Barry
___
On Apr 24, 2015, at 11:17 PM, Steven D'Aprano wrote:
>It seems to me that tools that search for r"^\s*def\s+spam\s*\(" are
They would likely search for something like r"^\s*def\s+[a-zA-Z0-9_]+" which
will hit "def async spam" but not "async def".
Cheers,
-Barry
__
On Thu, Apr 23, 2015 at 01:51:52PM -0400, Barry Warsaw wrote:
> Why "async def" and not "def async"?
>
> My concern is about existing tools that already know that "def" as the first
> non-whitespace on the line starts a function/method definition. Think of a
> regexp in an IDE that searches back
On Fri, Apr 24, 2015 at 3:14 AM, Greg Ewing wrote:
> Andrew Svetlov wrote:
>
>> But we already have asyncio and code based on asyncio coroutines.
>> To make it work I should always use costart() in places where asyncio
>> requires coroutine.
>
>
> As I understand it, asyncio would require changes
Stephen J. Turnbull wrote:
Yury Selivanov writes:
> I also read "for async item in iter:" as "I'm iterating iter
> with async item".
I thought that was precisely the intended semantics: item is available
asynchronously.
The async-at-the-end idea could be used here as well.
for item in i
Yury Selivanov wrote:
In a PEP 3152 aware version of asyncio, it's just *not
possible to write*
cocall gather(coro1(1,2), coro(2,3))
you just have to use your 'costart' built-in:
cocall gather(costart(coro1, 1, 2), costart(coro, 2,3)).
Another way to write that would be
cocall gather(Task
Yury Selivanov wrote:
If you have a future object 'fut', it's not intuitive
or pythonic to write 'cocall fut()'.
Another way to approach that would be to provide
a cofunction await() used like this:
cocall await(fut)
That would read more naturally and wouldn't require
modifying fut at all
Barry Warsaw wrote:
Sure, tools can be updated but it is it *necessary*
to choose a syntax that breaks tools?
def async useful():
seems okay to me.
That will break any tool that assumes the word following
'def' is the name of the function being defined.
Putting it at the end would seem l
Yury Selivanov writes:
> To my eye 'async def name()', 'async with', 'async for' look
> better than 'def async name()', 'with async' and 'for async'.
> But that's highly subjective.
I'm with Barry on this one as far as looks go. (But count that as a
+0, since I'm just a literary critic, I don
Andrew Svetlov wrote:
But we already have asyncio and code based on asyncio coroutines.
To make it work I should always use costart() in places where asyncio
requires coroutine.
As I understand it, asyncio would require changes to
make it work seamlessly with PEP 492 as well, since
an object n
> On Apr 23, 2015, at 10:51 AM, Barry Warsaw wrote:
>
> (I have mild concerns about __a*__ magic methods, since I think they'll be
> harder to visually separate, but here the PEP does describe the __async_*__
> alternatives.)
Has it been historically a problem with __iadd__ vs __radd__ vs __add
On 2015-04-23 3:03 AM, Greg Ewing wrote:
Yury Selivanov wrote:
- If it's an object with __await__, return iter(object.__await__())
Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?
I wrote it the wrong way. iter() isn't needed, you're ri
Barry,
On 2015-04-23 2:12 PM, Barry Warsaw wrote:
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:
To my eye 'async def name()', 'async with', 'async for' look
better than 'def async name()', 'with async' and 'for async'.
But that's highly subjective.
Would you be willing to add this as an
On 2015-04-23 18:51, Barry Warsaw wrote:
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want to mildly bik
On Apr 23, 2015, at 02:02 PM, Yury Selivanov wrote:
>To my eye 'async def name()', 'async with', 'async for' look
>better than 'def async name()', 'with async' and 'for async'.
>But that's highly subjective.
Would you be willing to add this as an alternative to the PEP, under the "Why
async def"
Hi Barry,
On 2015-04-23 1:51 PM, Barry Warsaw wrote:
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
The updated version of the PEP should be available shortly at
https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want t
On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote:
>The updated version of the PEP should be available shortly at
>https://www.python.org/dev/peps/pep-0492 and is also pasted in this email.
There's a lot to like about PEP 492. I only want to mildly bikeshed a bit on
the proposed new syntax.
Wh
Wolfgang,
On 2015-04-23 12:58 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov
wrote:
> Wolfgang,
>
>
> On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
>> wrote:
>>
>> Hi Wolfgang,
>>>
>>> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>>>
>>> On Thu, Apr 23, 2015 at 12:3
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlo
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
> Hi Wolfgang,
>
> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
>> wrote:
>>
>> Hello,
>>>
>>> On Thu, 23 Apr 2015 12:18:51 +0300
>>> Andrew Svetlov wrote:
>>>
>>> []
>>>
>>> 3.
>>>
Hi Wolfgang,
On 2015-04-23 11:57 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Sve
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov
wrote:
> Hi Wolfgang,
>
> On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
>
>> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky
>> wrote:
>>
>> Hello,
>>>
>>> On Thu, 23 Apr 2015 12:18:51 +0300
>>> Andrew Svetlov wrote:
>>>
>>> []
>>>
>>> 3.
>>>
Hi,
On 2015-04-23 3:30 AM, Wolfgang Langner wrote:
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate async coroutines from generators. So
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov wrote:
[]
3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every
On Thu, Apr 23, 2015 at 3:27 PM, Wolfgang Langner
wrote:
>
>
> On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote:
>>
>> Hello,
>>
>> On Thu, 23 Apr 2015 12:18:51 +0300
>> Andrew Svetlov wrote:
>>
>> []
>>
>> > > 3.
>> > > async with and async for
>> > > Bead idea, we clutter the language e
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov wrote:
[]
> > 3.
> > async with and async for
> > Bead idea, we clutter the language even more and it is one more
> > thing every newbie could do wrong.
> > for x in y:
> > result = await f()
> > is enough, every 'async' framework lived
Hello,
On Thu, 23 Apr 2015 20:39:51 +1200
Greg Ewing wrote:
> Paul Sokolovsky wrote:
> > And having both asymmetric and symmetric
> > would quite confusing, especially that symmetric are more powerful
> > and asymmetric can be easily implemented in terms of symmetric using
> > continuation-passi
On 2015-04-23 9:01 AM, Yury Selivanov wrote:
cocall fut() # instead of just cocall fut()
Should be:
cocall fut() # instead of just cocall fut
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
On 2015-04-23 8:10 AM, Greg Ewing wrote:
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart
call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept coroutines or
futures as parameters, n
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 23 Apr 2015 12:18:51 +0300
> Andrew Svetlov wrote:
>
> []
>
> > > 3.
> > > async with and async for
> > > Bead idea, we clutter the language even more and it is one more
> > > thing every newbie could do wrong.
> > > f
On Thu, Apr 23, 2015 at 3:10 PM, Greg Ewing wrote:
> Andrew Svetlov wrote:
>>
>> From my understanding to use cofunctions I must wrap it with costart call:
>>
>> yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
>>
>> There are other places in asyncio API those accept coroutines or
>
Paul Sokolovsky wrote:
Greg Ewing wrote:
You can also use a trampoline of some kind to
relay values back and forth between generators,
to get something symmetric.
Yes, that's of course how coroutine frameworks were done long before
"yield from" appeared and how Trollius works now.
No, what
Andrew Svetlov wrote:
From my understanding to use cofunctions I must wrap it with costart call:
yield from gather(costart(coro1, a1, a2), costart(coro2), fut3)
There are other places in asyncio API those accept coroutines or
futures as parameters, not only Task() and async().
In a PEP 3152 a
Yury Selivanov wrote:
So you would have to write 'await fut()'? This is non-intuitive.
That's because PEP 492 and its terminology encourage you
to think of 'await f()' as a two-step process: evaluate f(),
and then wait for the thing it returns to produce a
result.
PEP 3152 has a different ph
Greg, how waiting for multiple cocalls should look and work?
In asyncio when I need to wait for two and more coroutines/futures I
use `asyncio.gather()`:
yield from gather(coro1(a1, a2), coro2(), fut3)
>From my understanding to use cofunctions I must wrap it with costart call:
yield from gather
Yury Selivanov wrote:
I think that the problem of forgetting 'yield from' is a bit
exaggerated. Yes, I myself forgot 'yield from' once or twice. But that's
it, it has never happened since.
I think it's more likely to happen when you start with
an ordinary function, then discover that it needs
On Thu, Apr 23, 2015 at 10:30 AM, Wolfgang Langner
wrote:
> Hi,
>
> most of the time I am a silent reader but in this discussion I must step in.
> I use twisted and async stuff a lot over years followed development of
> asyncio closely.
>
> First it is good to do differentiate async coroutines fro
Yury Selivanov wrote:
So how would we do "await fut" if await requires parentheses?
I've answered this with respect to PEP 3152 -- futures would
implement __cocall__, so you would write 'cocall fut()'.
I'm not sure what to say about PEP 492 here, because it
depends on exactly what a version o
Hi,
I agree with most of Wolfgang's points below. As a data point, I
haven't used asyncio for anything real (despite having approved the
PEP!), but I have some extensive prior experience with Twisted and
Tornado :-)
Regards
Antoine.
On Thu, 23 Apr 2015 09:30:30 +0200
Wolfgang Langner wrote:
Paul Sokolovsky wrote:
And having both asymmetric and symmetric
would quite confusing, especially that symmetric are more powerful and
asymmetric can be easily implemented in terms of symmetric using
continuation-passing style.
You can also use a trampoline of some kind to
relay values back and
Ludovic Gasc wrote:
Not related, but one of my coworkers asked me if with the new syntax it
will be possible to write an async decorator for coroutines.
This is certainly possible with PEP 3152. The decorator
just needs to be an ordinary function whose return
value is a cofunction.
--
Greg
__
Victor Stinner wrote:
Using a custom name like "cofunction" may confuse users coming from other
programming languages. I prefer to keep "coroutine", but I agree that we
should make some effort to define the different categories of "Python
coroutines".
I should perhaps point out that "cofunctio
Victor Stinner wrote:
A huge part of the asyncio module is based on "yield from fut" where fut is
a Future object.
How do you write this using the PEP 3152? Do you need to call an artifical
method like "cocall fut.return_self()" where the return_self() method simply
returns fut?
In a PEP 3152
Hi,
most of the time I am a silent reader but in this discussion I must step in.
I use twisted and async stuff a lot over years followed development of
asyncio closely.
First it is good to do differentiate async coroutines from generators. So
everyone can see it and have this in mind
and don't mi
Yury Selivanov wrote:
- If it's an object with __await__, return iter(object.__await__())
Is the iter() really needed? Couldn't the contract of
__await__ be that it always returns an iterator?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
PJ Eby wrote:
I find this a little weird. Why not just have `with` and `for` inside
a coroutine dynamically check the iterator or context manager, and
either behave sync or async accordingly? Why must there be a
*syntactic* difference?
It depends on whether you think it's important to
have a
Yury Selivanov wrote:
I think there is another way... instead of pushing
GET_ITER
...
YIELD_FROM
opcodes, we'll need to replace GET_ITER with another one:
GET_ITER_SPECIAL
...
YIELD_FROM
I'm lost. What Python code are you suggesting this
would be generated from?
--
Greg
On 23/04/2015 6:32 a.m., Andrew Svetlov wrote:
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `async def` everywhere in asyncio API where
asyncio.coroutine required.
As I suggested earlier, a way could be provided to mark a
function as callable usin
On 04/23/2015 04:18 AM, Yury Selivanov wrote:
2. We'll hack Gen(/ceval.c?) objects to raise an error if they
are called directly and have a 'CO_COROUTINE' flag.
By "Gen", do you mean the generator-function or the
generator-iterator?
That flag has to be on the generator-function, not the
gener
I guess to raise exception on unwinded async generator in destructor
even in non-debug mode.
Debug mode may have more complex info with source_traceback included,
as Victor Stinner does for CoroWrapper.
On Thu, Apr 23, 2015 at 4:27 AM, Yury Selivanov wrote:
> Greg,
>
> On 2015-04-22 7:47 PM, Gre
Greg,
On 2015-04-22 7:47 PM, Greg Ewing wrote:
Yury Selivanov wrote:
On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions. That feels non-pytonic to me.
How is it any different from grammatically requiring
parens in an ordinary function call? Nob
On Thu, Apr 23, 2015 at 3:35 AM, Guido van Rossum wrote:
> On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
> wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
>>> wrap a coroutine in a Task, the way its done in asyncio by the Task()
>
On 2015-04-22 9:04 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you h
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov
wrote:
> On 2015-04-22 8:35 PM, Guido van Rossum wrote:
>
>> On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
>> wrote:
>>
>> Guido van Rossum wrote:
>>>
>>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
wrap a coroutine
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
wrap a coroutine in a Task, the way its done in asyncio by the Task()
constructor, the loop.create
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to
>> wrap a coroutine in a Task, the way its done in asyncio by the Task()
>> constructor, the loop.create_task() method, and the async() functio
Guido van Rossum wrote:
On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to wrap a coroutine
in a Task, the way its done in asyncio by the Task() constructor, the
loop.create_task() method, and the async() function
That's easy. You can always use costart() to adapt a cofunc
Yury Selivanov wrote:
On the other hand, I hate the idea
of grammatically requiring parentheses for 'await'
expressions. That feels non-pytonic to me.
How is it any different from grammatically requiring
parens in an ordinary function call? Nobody ever
complained about that.
In the PEP 3152
Hello,
On Wed, 22 Apr 2015 09:53:39 -0700
Rajiv Kumar wrote:
> I'd like to suggest another way around some of the issues here, with
> apologies if this has already been discussed sometime in the past.
>
> From the viewpoint of a Python programmer, there are two distinct
> reasons for wanting to
Hello,
On Wed, 22 Apr 2015 13:31:18 -0700
Guido van Rossum wrote:
> On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
> wrote:
>
> > On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby
> > wrote:
> > > On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> > >
> > wrote:
> > >> It is an error to pass a regula
Ludovic,
On 2015-04-22 5:00 PM, Ludovic Gasc wrote:
Not related, but one of my coworkers asked me if with the new syntax it
will be possible to write an async decorator for coroutines.
If I understand correctly new grammar in PEP, it seems to be yes, but could
you confirm ?
There shouldn't be
2015-04-22 22:46 GMT+02:00 Victor Stinner :
>
> Kind (A):
>
> - "yield-from coroutines" or "coroutines based on yield-from"
> - maybe "asyncio coroutines"
> - "legacy coroutines"?
>
"legacy coroutines" name has the advantage to be directly clear it isn't a
good idea to write new source code with t
Greg Ewing canterbury.ac.nz> writes:
> I still don't like the idea of hijacking the generic
> term "coroutine" and using it to mean this particular
> type of object.
There are only two hard things in Computer Science: cache invalidation
and naming things.
-- Phil Karlton
:-)
When revie
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
wrote:
> On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby wrote:
> > On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> wrote:
> >> It is an error to pass a regular context manager without ``__aenter__``
> >> and ``__aexit__`` methods to ``async with``. I
Hi,
Guido van Rossum python.org> writes:
> I'm slowly warming up to Greg's notion that you can't call a coroutine (or
whatever it's called) without a special keyword.
A huge part of the asyncio module is based on "yield from fut" where fut is
a Future object.
How do you write this using the PEP
Hi PJ,
On 2015-04-22 3:44 PM, PJ Eby wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
It is an error to pass a regular context manager without ``__aenter__``
and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
to use ``async with`` outside of a coroutine.
I find
+1 about Andrew Svetlov proposition: please help to migrate as smoothly as
possible to async/await.
--
Ludovic Gasc (GMLudo)
http://www.gmludo.eu/
2015-04-22 20:32 GMT+02:00 Andrew Svetlov :
> For now I can use mix asyncio.coroutines and `async def` functions, I
> mean I can write `await f()` in
On 04/22, PJ Eby wrote:
> tl;dr: I like the overall ideas but hate the syntax and type
> segregation involved: declaring a function async at the top is OK to
> enable async with/for semantics and await expressions, but the rest
> seems unnecessary and bad for writing robust code. (e.g. note that
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby wrote:
> On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
> wrote:
>> It is an error to pass a regular context manager without ``__aenter__``
>> and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
>> to use ``async with`` outside of a cor
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov wrote:
> It is an error to pass a regular context manager without ``__aenter__``
> and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
> to use ``async with`` outside of a coroutine.
I find this a little weird. Why not just have `
On Wed, Apr 22, 2015 at 10:24 PM, Yury Selivanov
wrote:
>
>
> On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
>>
>> On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov
>> wrote:
>
> [...]
>>>
>>>
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `asyn
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov wrote:
[...]
If we forbid to call `async def` from regualr code how asyncio should
work? I'd like to push `async def` everywhere in asyncio API where
asyncio.coroutine required.
You'll have to us
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov wrote:
> Andrew,
>
> On 2015-04-22 2:32 PM, Andrew Svetlov wrote:
>>
>> For now I can use mix asyncio.coroutines and `async def` functions, I
>> mean I can write `await f()` inside async def to call
>> asyncio.coroutine `f` and vise versa: I can use
Andrew,
On 2015-04-22 2:32 PM, Andrew Svetlov wrote:
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I can write `await f()` inside async def to call
asyncio.coroutine `f` and vise versa: I can use `yield from g()`
inside asyncio.coroutine to call `async def g(): ...`.
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I can write `await f()` inside async def to call
asyncio.coroutine `f` and vise versa: I can use `yield from g()`
inside asyncio.coroutine to call `async def g(): ...`.
If we forbid to call `async def` from regualr code how
Hi Rajiv,
On 2015-04-22 12:53 PM, Rajiv Kumar wrote:
I'd like to suggest another way around some of the issues here, with
apologies if this has already been discussed sometime in the past.
From the viewpoint of a Python programmer, there are two distinct reasons
for wanting to suspend executio
I'd like to suggest another way around some of the issues here, with
apologies if this has already been discussed sometime in the past.
>From the viewpoint of a Python programmer, there are two distinct reasons
for wanting to suspend execution in a block of code:
1. To yield a value from an itera
Hi Guido,
On 2015-04-22 11:50 AM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov
wrote:
On the one hand I like your idea to disallow calling
coroutines without a special keyword (await in case of
PEP 492). It has downsides, but there is some
elegance in it. On the ot
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov
wrote:
>
> On the one hand I like your idea to disallow calling
> coroutines without a special keyword (await in case of
> PEP 492). It has downsides, but there is some
> elegance in it. On the other hand, I hate the idea
> of grammatically requiri
Hi Greg,
On 2015-04-22 2:05 AM, Greg Ewing wrote:
Yury Selivanov wrote:
1. CO_ASYNC flag was renamed to CO_COROUTINE;
2. sys.set_async_wrapper() was renamed to
sys.set_coroutine_wrapper();
3. New function: sys.get_coroutine_wrapper();
4. types.async_def() renamed to types.coroutine();
I
Yury Selivanov wrote:
1. CO_ASYNC flag was renamed to CO_COROUTINE;
2. sys.set_async_wrapper() was renamed to
sys.set_coroutine_wrapper();
3. New function: sys.get_coroutine_wrapper();
4. types.async_def() renamed to types.coroutine();
I still don't like the idea of hijacking the generic
Hi Damien,
Thanks for noticing! I pushed a fix to the peps repo.
Thanks,
Yury
On 2015-04-21 5:20 PM, Damien George wrote:
Hi Yury,
In your PEP 492 draft, in the Grammar section, I think you're missing
the modifications to the "flow_stmt" line.
Cheers,
Damien.
___
Hi Yury,
In your PEP 492 draft, in the Grammar section, I think you're missing
the modifications to the "flow_stmt" line.
Cheers,
Damien.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hi python-dev,
I'm moving the discussion from python-ideas to here.
The updated version of the PEP should be available shortly
at https://www.python.org/dev/peps/pep-0492
and is also pasted in this email.
Updates:
1. CO_ASYNC flag was renamed to CO_COROUTINE;
2. sys.set_async_wrapper() was re
94 matches
Mail list logo
