Re: [Python-Dev] PEP 492 quibble and request

On 05/03/2015 03:03 PM, Arnaud Delobelle wrote: On 3 May 2015 at 02:22, Greg Ewing wrote: >Guido van Rossum wrote: >> >>On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle >> wrote: >> >> Does this mean that >> somehow "await x" guarantees that the coroutine wi

Re: [Python-Dev] PEP 492 quibble and request

On 3 May 2015 at 02:22, Greg Ewing wrote: > Guido van Rossum wrote: >> >> On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > > wrote: >> >> Does this mean that >> somehow "await x" guarantees that the coroutine will suspend at least >> once? > > > No. First, i

Re: [Python-Dev] PEP 492 quibble and request

On 1 May 2015 at 20:59, Guido van Rossum wrote: > On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: >> >> >> Another useful async function might be... >> >>async def yielding(): >>pass >> >> In a routine is taking very long time, just inserting "await yielding()" >> in the long calcula

Re: [Python-Dev] PEP 492 quibble and request

Guido van Rossum wrote: On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle > wrote: Does this mean that somehow "await x" guarantees that the coroutine will suspend at least once? No. First, it's possible for x to finish without yielding. But even if x yield

Re: [Python-Dev] PEP 492 quibble and request

On Sat, May 2, 2015 at 1:18 PM, Arnaud Delobelle wrote: > On 1 May 2015 at 20:59, Guido van Rossum wrote: > > On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: > >> > >> > >> Another useful async function might be... > >> > >>async def yielding(): > >>pass > >> > >> In a routine is t

Re: [Python-Dev] PEP 492 quibble and request

On 05/02/2015 04:18 PM, Arnaud Delobelle wrote: On 1 May 2015 at 20:59, Guido van Rossum wrote: >On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: >> >> >>Another useful async function might be... >> >>async def yielding(): >>pass >> >>In a routine is taking very long time, just in

Re: [Python-Dev] PEP 492 quibble and request

:p.f.mo...@gmail.com> Sent: ‎4/‎30/‎2015 2:07 To: Greg Ewing<mailto:greg.ew...@canterbury.ac.nz> Cc: Python Dev<mailto:python-dev@python.org> Subject: Re: [Python-Dev] PEP 492 quibble and request On 30 April 2015 at 09:58, Greg Ewing wrote: > Ethan Furman wrote: >> >> Ha

Re: [Python-Dev] PEP 492 quibble and request

On Fri, May 1, 2015 at 12:49 PM, Ron Adam wrote: > > Another useful async function might be... > >async def yielding(): >pass > > In a routine is taking very long time, just inserting "await yielding()" > in the long calculation would let other awaitables run. > > That's really up to

Re: [Python-Dev] PEP 492 quibble and request

On 05/01/2015 07:54 AM, Steven D'Aprano wrote: On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote: >Ah, but here's the other clever bit: it's only interpreted this way >*inside* a function declared with 'async def'. Outside such functions, >'await' is not a keyword, so that gra

Re: [Python-Dev] PEP 492 quibble and request

On 1 May 2015 at 12:54, Steven D'Aprano wrote: > You mean we could write code like this? > > def await(x): > ... > > > if condition: > async def spam(): > await (eggs or cheese) > else: > def spam(): > await(eggs or cheese) > > > I must admit that's kind of cool, but I'

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 07:31:22PM -0700, Guido van Rossum wrote: > Ah, but here's the other clever bit: it's only interpreted this way > *inside* a function declared with 'async def'. Outside such functions, > 'await' is not a keyword, so that grammar rule doesn't trigger. (Kind of > similar to t

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 06:12:37PM -0700, Guido van Rossum wrote: > On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote: > > > On 30 April 2015 at 10:21, Ethan Furman wrote: > > > From the PEP: > > > > > >> Why not a __future__ import > > >> > > >> __future__ imports are inconvenient and easy to

Re: [Python-Dev] PEP 492 quibble and request

On Thu, 30 Apr 2015 10:02:17 +0100 Paul Moore wrote: > > Of course, if asyncio and the PEP *are* only really relevant to > network protocols, then my impressions are actually correct and I > should drop out of the discussion. But if that's the case, it seems > like a lot of language change for a

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 09:58, Greg Ewing wrote: > Ethan Furman wrote: >> >> Having gone through the PEP again, I am still no closer to understanding >> what happens here: >> >> data = await reader.read(8192) >> >> What does the flow of control look like at the interpreter level? > > > Are you sure

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 02:52, Nick Coghlan wrote: > This request isn't about understanding the implementation details, > it's about understanding what Python *users* will gain from the PEP > without *needing* to understand the implementation details. > > For that, I'd like to see some not-completely-

Re: [Python-Dev] PEP 492 quibble and request

Ethan Furman wrote: Having gone through the PEP again, I am still no closer to understanding what happens here: data = await reader.read(8192) What does the flow of control look like at the interpreter level? Are you sure you *really* want to know? For the sake of sanity, I recommend ignori

Re: [Python-Dev] PEP 492 quibble and request

Hello, On Wed, 29 Apr 2015 20:33:09 -0400 Yury Selivanov wrote: > 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 us

Re: [Python-Dev] PEP 492 quibble and request

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 wrote: > On 30 April 2015 at 12:31, Guido van Rossum wrote: > > On Wed, Apr 29, 2015 at 7:07 PM,

Re: [Python-Dev] PEP 492 quibble and request

On 2015-04-29 11:01 PM, Nick Coghlan wrote: On 30 April 2015 at 12:31, Guido van Rossum wrote: >On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan 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

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 12:31, Guido van Rossum wrote: > On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan 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

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 7:07 PM, Nick Coghlan 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 avoid changing t

Re: [Python-Dev] PEP 492 quibble and request

Nick, On 2015-04-29 9:52 PM, Nick Coghlan wrote: On 30 April 2015 at 10:33, Yury Selivanov 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

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 11:12, Guido van Rossum wrote: > On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan 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 wouldn't mind > if a highlighter al

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 10:33, Yury Selivanov 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 implemented in PEP 49

Re: [Python-Dev] PEP 492 quibble and request

On Wed, Apr 29, 2015 at 5:59 PM, Nick Coghlan wrote: > On 30 April 2015 at 10:21, 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

Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 10:21, 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. ;) It is also ma

Re: [Python-Dev] PEP 492 quibble and request

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 .

[Python-Dev] PEP 492 quibble and request

>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 a