On 25 April 2015 at 22:02, Yury Selivanov yselivanov...@gmail.com 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
Le 25 avr. 2015 23:02, Yury Selivanov yselivanov...@gmail.com 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
Hi Arnaud,
On 2015-04-25 4:47 PM, Arnaud Delobelle wrote:
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov yselivanov...@gmail.com 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
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov yselivanov...@gmail.com 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,
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 greg.ew...@canterbury.ac.nz wrote:
Wild idea:
Let @ mean async when it's directly in front
of a keyword.
Then we would have:
@def f():
...
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 iter
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
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
On Fri, Apr 24, 2015 at 3:14 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
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 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 backwards from
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 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 spam but not
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
On Apr 24, 2015, at 6:32 AM, Barry Warsaw ba...@python.org 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
Hello,
On Fri, 24 Apr 2015 12:04:27 -0700
Łukasz Langa luk...@langa.pl 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,
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
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Bead idea, we clutter the language
Hi Wolfgang,
On 2015-04-23 11:57 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu,
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On
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
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
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
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
On 2015-04-23 8:27 AM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com
wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov
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.
Why
On Apr 23, 2015, at 10:51 AM, Barry Warsaw ba...@python.org 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
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
Wolfgang,
On 2015-04-23 12:58 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 6:22 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Wolfgang,
On 2015-04-23 12:12 PM, Wolfgang Langner wrote:
On Thu, Apr 23, 2015 at 5:32 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Hi Wolfgang,
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
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
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
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
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,
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
Hello,
On Thu, 23 Apr 2015 20:39:51 +1200
Greg Ewing greg.ew...@canterbury.ac.nz 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
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com 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'
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
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 cofunction is
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
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
On Thu, Apr 23, 2015 at 10:30 AM, Wolfgang Langner
tds333+py...@gmail.com 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
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
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
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
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 of
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
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
Paul Sokolovsky wrote:
Greg Ewing greg.ew...@canterbury.ac.nz 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
On Thu, Apr 23, 2015 at 3:10 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
Bead idea, we clutter the language even more and it is one more
thing every newbie
On Thu, Apr 23, 2015 at 3:27 PM, Wolfgang Langner
tds333+py...@gmail.com wrote:
On Thu, Apr 23, 2015 at 12:35 PM, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 23 Apr 2015 12:18:51 +0300
Andrew Svetlov andrew.svet...@gmail.com wrote:
[]
3.
async with and async for
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
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
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't
Hi Guido,
On 2015-04-22 11:50 AM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov yselivanov...@gmail.com
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
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
On Wed, Apr 22, 2015 at 8:40 AM, Yury Selivanov yselivanov...@gmail.com
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
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();
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 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
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
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com 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
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():
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com 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
On Wed, Apr 22, 2015 at 10:24 PM, Yury Selivanov
yselivanov...@gmail.com wrote:
On 2015-04-22 2:53 PM, Andrew Svetlov wrote:
On Wed, Apr 22, 2015 at 9:45 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
[...]
If we forbid to call `async def` from regualr code how asyncio should
work?
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com 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.
Greg Ewing greg.ewing at 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
:-)
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
On 2015-04-22 9:04 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
On Wed,
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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 Thu, Apr 23, 2015 at 3:35 AM, Guido van Rossum gu...@python.org wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
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?
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 yselivanov...@gmail.com wrote:
Greg,
On
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
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
On Wed, Apr 22, 2015 at 5:55 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
On 2015-04-22 8:35 PM, Guido van Rossum wrote:
On Wed, Apr 22, 2015 at 5:12 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
On Wed, Apr 22, OTOH I'm still struggling with what you
2015-04-22 22:46 GMT+02:00 Victor Stinner victor.stin...@gmail.com:
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
Hello,
On Wed, 22 Apr 2015 13:31:18 -0700
Guido van Rossum gu...@python.org wrote:
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov
andrew.svet...@gmail.com wrote:
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com
wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov
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 rajiv.ku...@gmail.com 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
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
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
It is an error to pass a regular context manager without ``__aenter__``
and ``__aexit__`` methods to ``async with``. It is a ``SyntaxError``
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
+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 andrew.svet...@gmail.com:
For now I can use mix asyncio.coroutines and `async def` functions, I
mean I
Hi PJ,
On 2015-04-22 3:44 PM, PJ Eby wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com 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
Hi,
Guido van Rossum guido at 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
On Wed, Apr 22, 2015 at 1:10 PM, Andrew Svetlov andrew.svet...@gmail.com
wrote:
On Wed, Apr 22, 2015 at 10:44 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Apr 21, 2015 at 1:26 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
It is an error to pass a regular context manager without
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
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
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 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.
94 matches
Mail list logo
