Yury Selivanov wrote:
I also like Guido's suggestion to use native coroutine term.
I'll update the PEP (I have several branches of it in the repo
that I need to merge before the rename).
I'd still prefer to avoid use of the word coroutine
altogether as being far too overloaded.
I think even
Guido van Rossum wrote:
On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov yselivanov...@gmail.com
mailto:yselivanov...@gmail.com wrote:
Why StopAsyncIteration?
'''
I keep wanting to propose to rename this to AsyncStopIteration.
+1, that seems more consistent to
Yury Selivanov wrote:
It's just like unary minus ;)
I'm confused. I thought you were arguing that your
grammar is better because it's *not* just like unary
minus?
If being just like unary minus is okay, then why
not just make it so?
--
Greg
___
Yury Selivanov wrote:
Looking at the grammar -- the only downside of the current approach is that
you can't do 'await await fut'. I still think that it reads better with
parens. If we put 'await' to 'factor' terminal we would allow
await -fut # await (-fut)
Is there really a need to
Yury Selivanov wrote:
It's important to at least have 'iscoroutine' -- to check that
the object is a coroutine function. A typical use-case would be
a web framework that lets you to bind coroutines to specific
http methods/paths:
@http.get('/spam')
async def handle_spam(request):
Yury Selivanov wrote:
On 2015-04-28 11:59 PM, Greg wrote:
On 29/04/2015 9:49 a.m., Guido van Rossum wrote:
*But* every generator-based coroutine *must* be
decorated with `asyncio.coroutine()`. This is
potentially a backwards incompatible change.
See below. I worry about
Yury Selivanov wrote:
3. GenObject __iter__ and __next__ raise error
*only* if it has CO_NATIVE_COROUTINE flag. So
iter(), next(), for..in aren't supported only
for 'async def' functions (but will work ok
on asyncio generator-based coroutines)
What about new 'async def' code called by
On 29 April 2015 at 06:20, Adam Bartoš dre...@gmail.com wrote:
Hello,
is it possible to somehow tell Python 2.7 to compile a code entered in the
interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm considering
adding support for Python 2 in my package
This situation is a bit different from coding cookies. They are used when
we have bytes from a source file, but we don't know its encoding. During
interactive session the tokenizer always knows the encoding of the bytes. I
would think that in the case of interactive session the PyCF_SOURCE_IS_UTF8
Guido van Rossum wrote:
There's a cost to __future__ imports
too. The current proposal is a pretty clever hack -- and we've done
similar hacks in the past
There's a benefit to having a __future__ import beyond
avoiding hackery: by turning on the __future__ you can
find out what will break
Guido van Rossum wrote:
I don't care for await await x.
But do you dislike it enough to go out of your way
to disallow it?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
—
Sent from Mailbox
On Wednesday Apr 29, 2015 at 7:14 PM, Yury Selivanov yselivanov...@gmail.com,
wrote:Also please see this:
https://hg.python.org/peps/rev/d048458307b7
FWIW, 'await await fut' isn't something that you likely to see in
your life; 'await -fut' is 99.999% just a bug.
Agree.
Ethan,
On 2015-04-29 11:29 AM, Ethan Furman wrote:
Python is not lisp, and await is not a
function, so parens should not be needed in the common case.
Which common case you mean?
Please see this table
https://www.python.org/dev/peps/pep-0492/#syntax-of-await-expression
Yury
I suspect the interactive session is *not* always in UTF8. It probably
depends on the keyboard mapping of your terminal emulator. I imagine in
Windows it's the current code page.
On Wed, Apr 29, 2015 at 9:19 AM, Adam Bartoš dre...@gmail.com wrote:
Yes, that works for eval. But I want it for
Yes, that works for eval. But I want it for code entered during an
interactive session.
u'α'
u'\xce\xb1'
The tokenizer gets bu'\xce\xb1' by calling PyOS_Readline and it knows
it's utf-8 encoded. But the result of evaluation is u'\xce\xb1'. Because of
how eval works, I believe that it would work
Also please see this:
https://hg.python.org/peps/rev/d048458307b7
FWIW, 'await await fut' isn't something that you likely to see in
your life; 'await -fut' is 99.999% just a bug. I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Yury
On 2015-04-29 11:33 AM, Yury Selivanov
On Apr 29, 2015 11:49 AM, Yury Selivanov yselivanov...@gmail.com wrote:
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan Furman wrote:
On 04/29, Yury Selivanov wrote:
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does
I am in Windows and my terminal isn't utf-8 at the beginning, but I install
custom sys.std* objects at runtime and I also install custom readline hook,
so the interactive loop gets the input from my stream objects via
PyOS_Readline. So when I enter u'α', the tokenizer gets bu'\xce\xb1',
which is
Ethan,
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
On Wed, Apr 29, 2015 at 1:14 PM, Skip Montanaro
skip.montan...@gmail.com wrote:
On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Anyways, I'd be OK to start using a new term, if coroutine is
confusing.
According to Wikipedia, term coroutine was first coined
On 29 April 2015 at 19:42, Yury Selivanov yselivanov...@gmail.com wrote:
Here's how it might look like (this is the same pseudo-code
but tailored for PEP 492, not a real something)
q = asyncio.Queue(maxsize=100)
async def produce():
# you might want to wrap it all in 'while True'
Hi Nathaniel,
BTW, I'm going to reply to you in the other thread about
context-local objects soon. I have some thoughts on the
topic.
On 2015-04-29 3:14 PM, Nathaniel Smith wrote:
On Apr 29, 2015 11:49 AM, Yury Selivanov yselivanov...@gmail.com wrote:
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan
Paul,
On 2015-04-29 3:19 PM, Paul Moore wrote:
On 29 April 2015 at 19:42, Yury Selivanov yselivanov...@gmail.com wrote:
Here's how it might look like (this is the same pseudo-code
but tailored for PEP 492, not a real something)
q = asyncio.Queue(maxsize=100)
async def produce():
On Wed, Apr 29, 2015 at 2:42 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Anyways, I'd be OK to start using a new term, if coroutine is
confusing.
According to Wikipedia http://en.wikipedia.org/wiki/Coroutine, term
coroutine was first coined in 1958, so several generations of computer
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in PEP
380. This approach has a number of
On 29 April 2015 at 19:32, Ethan Furman et...@stoneleaf.us wrote:
On 04/29, Yury Selivanov wrote:
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
I obviously don't understand your position
On 29 April 2015 at 18:43, Jim J. Jewett jimjjew...@gmail.com wrote:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in PEP
380. This approach has a number of
On 04/29, Yury Selivanov wrote:
On 2015-04-29 11:29 AM, Ethan Furman wrote:
Python is not lisp, and await is not a
function, so parens should not be needed in the common case.
Which common case you mean?
The common case of not wanting to write parenthesis. ;)
Seriously, why are the parens
On 04/29, Yury Selivanov wrote:
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
I obviously don't understand your position that it does not make
any sense -- perhaps you could explain a bit?
Hi Paul,
On 2015-04-29 2:26 PM, Paul Moore wrote:
On 29 April 2015 at 18:43, Jim J. Jewett jimjjew...@gmail.com wrote:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in
On Wed, Apr 29, 2015 at 09:40:43AM -0700, Guido van Rossum gu...@python.org
wrote:
I suspect the interactive session is *not* always in UTF8. It probably
depends on the keyboard mapping of your terminal emulator. I imagine in
Windows it's the current code page.
Even worse: in w32 it can be
Hi Jim,
On 2015-04-29 1:43 PM, Jim J. Jewett wrote:
On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492:
Rationale and Goals
===
Current Python supports implementing coroutines via generators (PEP
342), further enhanced by the ``yield from`` syntax introduced in
Hi Ethan,
On 2015-04-29 2:32 PM, Ethan Furman wrote:
On 04/29, Yury Selivanov wrote:
On 2015-04-29 1:25 PM, Ethan Furman wrote:
cannot also just work and be the same as the parenthesized
version.
Because it does not make any sense.
I obviously don't understand your position that it does not
Maybe it would help to refer to PEP 342, which first formally introduced
the concept of coroutines (as a specific use case of generators) in Python.
Personally I don't care too much which term the PEP uses, as logn as it
defines its terms. The motivation is already clear to me; it's the details
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable description of*what it is*. AFAICT the
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable description of*what it is*. AFAICT the
Guido,
On 2015-04-29 7:52 PM, Guido van Rossum wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate
Yury Selivanov wrote:
I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Because I believe that any extra complexity in the grammar
needs a very strong justification. It's complexity in the
core language, like a new keyword, so it puts a burden on
everyone's brain.
Saying I
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not using an import. By that logic we
should have everything in built-ins. ;)
Working example
...
The working example only uses async def and await,
On 29 April 2015 at 20:42, Yury Selivanov yselivanov...@gmail.com wrote:
Everybody is pulling me in a different direction :)
Sorry :-)
Guido proposed to call them native coroutines. Some people
think that async functions is a better name. Greg loves
his cofunction term.
If it helps,
Greg,
On 2015-04-29 6:46 PM, Greg Ewing wrote:
Yury Selivanov wrote:
I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Because I believe that any extra complexity in the grammar
needs a very strong justification. It's complexity in the
core language, like a new keyword, so
On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Yury Selivanov wrote:
I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Because I believe that any extra complexity in the grammar
needs a very strong justification. It's complexity in the
On Wed, Apr 29, 2015 at 5:05 PM, Yury Selivanov yselivanov...@gmail.com wrote:
Nathaniel,
On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com
wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel
On 2015-04-29 3:24 PM, Isaac Schwabacher wrote:
On 15-04-29, Yury Selivanov wrote:
Hi Ethan,
[..]
So I want to make this syntactically incorrect:
Does this need to be a syntax error? -hello raises TypeError because str doesn't have a
__neg__, but there's no reason a str subclass couldn't
Yury Selivanov wrote:
Won't that prevent some existing generator-based
coroutines (ones not decorated with @coroutine)
from calling ones implemented with 'async def'?
It would. But that's not a backwards compatibility
issue.
It seems to go against Guido's desire for the new
way to be a
Greg,
On 2015-04-29 6:46 PM, Greg Ewing wrote:
Yury Selivanov wrote:
Won't that prevent some existing generator-based
coroutines (ones not decorated with @coroutine)
from calling ones implemented with 'async def'?
It would. But that's not a backwards compatibility
issue.
It seems to go
On Wed, Apr 29, 2015 at 3:46 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Yury Selivanov wrote:
I'm not sure
why Greg is pushing his Grammar idea so aggressively.
Because I believe that any extra complexity in the grammar
needs a very strong justification. It's complexity in the
core
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
accurate human-readable description of*what it is*. AFAICT the PEP
currently doesn't have that.
How to define human-readable description of how
Nathaniel,
On 2015-04-29 7:58 PM, Nathaniel Smith wrote:
On Wed, Apr 29, 2015 at 4:48 PM, Yury Selivanov yselivanov...@gmail.com wrote:
Nathaniel,
On 2015-04-29 7:35 PM, Nathaniel Smith wrote:
What I do feel strongly about
is that whatever syntax we end up with, there should be*some*
On 2015-04-29 5:13 AM, Greg Ewing wrote:
Yury Selivanov wrote:
3. GenObject __iter__ and __next__ raise error
*only* if it has CO_NATIVE_COROUTINE flag. So
iter(), next(), for..in aren't supported only
for 'async def' functions (but will work ok
on asyncio generator-based coroutines)
What
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Yury Selivanov wrote:
Looking at the grammar -- the only downside of the current approach
is that
you can't do 'await await fut'. I still think that it reads better with
parens. If we put 'await' to 'factor' terminal we would allow
await -fut #
Yury Selivanov writes:
Agree. Do you think it'd be better to combine comprehensions
and async lambdas in one section?
No, I'd keep them separate. For one thing, given Guido's
long-standing lack of enthusiasm for lambda, they'll need to be
separate PEPs.
Greg,
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Guido van Rossum wrote:
On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov
yselivanov...@gmail.com mailto:yselivanov...@gmail.com wrote:
Why StopAsyncIteration?
'''
I keep wanting to propose to rename this to
Greg,
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Yury Selivanov wrote:
It's important to at least have 'iscoroutine' -- to check that
the object is a coroutine function. A typical use-case would be
a web framework that lets you to bind coroutines to specific
http methods/paths:
Greg,
On 2015-04-29 5:13 AM, Greg Ewing wrote:
Yury Selivanov wrote:
On 2015-04-28 11:59 PM, Greg wrote:
On 29/04/2015 9:49 a.m., Guido van Rossum wrote:
*But* every generator-based coroutine *must* be
decorated with `asyncio.coroutine()`. This is
potentially a backwards
Hi folks,
This is just a note to highlight the fact that I tweaked the Opting
out section in PEP 476 based on various discussions I've had over the
past few months: https://hg.python.org/peps/rev/dfd96ee9d6a8
The notable changes:
* the example monkeypatching code handles AttributeError when
Hi Ethan,
On 2015-04-29 8:21 PM, Ethan Furman wrote:
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not using an import. By that logic we
should have everything in built-ins. ;)
Working example
On 30 April 2015 at 10:21, Ethan Furman et...@stoneleaf.us wrote:
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not using an import. By that logic we
should have everything in built-ins. ;)
It is
Adam Bartoš writes:
I am in Windows and my terminal isn't utf-8 at the beginning, but I
install custom sys.std* objects at runtime and I also install
custom readline hook,
IIRC, on the Linux console and in an uxterm, PYTHONIOENCODING=utf-8 in
the environment does what you want. (Can't
On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 April 2015 at 10:21, Ethan Furman et...@stoneleaf.us wrote:
From the PEP:
Why not a __future__ import
__future__ imports are inconvenient and easy to forget to add.
That is a horrible rationale for not
On Thu, Apr 30, 2015 at 11:03 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
Note that even if you have a UTF-8 input source, some users are likely
to be surprised because IIRC Python doesn't canonicalize in its
codecs; that is left for higher-level libraries. Linux UTF-8 is
usually NFC
Nick,
On 2015-04-29 9:52 PM, Nick Coghlan wrote:
On 30 April 2015 at 10:33, Yury Selivanov yselivanov...@gmail.com wrote:
To really understand all implementation details of this line
you need to read PEP 3156 and experiment with asyncio. There
is no easier way, unfortunately. I can't add a
On 30 April 2015 at 12:31, Guido van Rossum gu...@python.org wrote:
On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan ncogh...@gmail.com wrote:
[...]
Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
can see that the proposal only allows its use in cases that were
previously
Hi python-dev,
New version of the PEP is attached. Summary of updates:
1. Terminology:
- *native coroutine* term is used for async def functions.
- *generator-based coroutine* term is used for PEP 380
coroutines used in asyncio.
- *coroutine* is used when *native coroutine* or
*generator
One more thing to discuss:
7. StopAsyncIteration vs AsyncStopIteration.
I don't have a strong opinion on this, I prefer
the former because it reads better.
There was no consensus on which one we should use.
Thanks,
Yury
___
Python-Dev mailing list
On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan ncogh...@gmail.com wrote:
[...]
Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
can see that the proposal only allows its use in cases that were
previously entirely illegal, but I'm not yet clear on how the PEP
proposes to
On 30 April 2015 at 10:33, Yury Selivanov yselivanov...@gmail.com wrote:
To really understand all implementation details of this line
you need to read PEP 3156 and experiment with asyncio. There
is no easier way, unfortunately. I can't add a super detailed
explanation how event loops can be
On 30 April 2015 at 11:12, Guido van Rossum gu...@python.org wrote:
On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan ncogh...@gmail.com wrote:
It is also makes things more painful than they need to be for syntax
highlighters.
Does it? Do highlighters even understand __future__ imports? I
On 04/29, Yury Selivanov wrote:
On 2015-04-29 5:12 AM, Greg Ewing wrote:
Yury Selivanov wrote:
Looking at the grammar -- the only downside of the current
approach is that
you can't do 'await await fut'. I still think that it reads better with
parens. If we put 'await' to 'factor' terminal
Paul Moore wrote:
I agree. While I don't use coroutines/asyncio, and I may never do so,
I will say that I find Python's approach very difficult to understand.
Well, I tried to offer something easier to understand.
The idea behind PEP 3152 is that writing async code
should be just like writing
Nathaniel Smith wrote:
(I suspect this may also be the impetus behind Greg's request that it
just be treated the same as unary minus. IMHO it matters much more that
the rules be predictable and teachable than that they allow or disallow
every weird edge case in exactly the right way.)
On 2015-04-29 11:01 PM, Nick Coghlan wrote:
On 30 April 2015 at 12:31, Guido van Rossumgu...@python.org wrote:
On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlanncogh...@gmail.com wrote:
[...]
Yeah, I'm coming around to the idea. For the async pseudo-keyword, I
can see that the proposal only
Belt and suspenders. :-)
We may need help with the implementation though -- PEP 479 is still waiting
on implementation help with __future__ too AFAIK.
On Wed, Apr 29, 2015 at 8:01 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 April 2015 at 12:31, Guido van Rossum gu...@python.org wrote:
Le 29 avr. 2015 10:36, Adam Bartoš dre...@gmail.com a écrit :
Why I'm talking about PyCF_SOURCE_IS_UTF8? eval(uu'\u03b1') -
u'\u03b1' but eval(uu'\u03b1'.encode('utf-8')) - u'\xce\xb1'.
There is a simple option to get this flag: call eval() with unicode, not
with encoded bytes.
Victor
74 matches
Mail list logo
