Re: [Python-Dev] PEP 492: async/await in Python; version 4

Paul Moore wrote: It would probably be helpful to have a concrete example of a basic event loop that did *nothing* but schedule tasks. No IO waiting or similar, just scheduling. Take a look at the example I developed when working on the yield-from pep: http://www.cosc.canterbury.ac.nz/greg.ewi

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On Tue, May 5, 2015 at 3:25 PM, Yury Selivanov wrote: > > Yes, there is no other popular event loop for 3.4 other > than asyncio, that uses coroutines based on generators > (as far as I know). > Tornado supports Python 3.4 and uses generator-based coroutines. We use `yield` instead of `yield fro

Re: [Python-Dev] PEP 492: async/await in Python; version 5

For this you should probably use an integration of asyncio (which can do async subprocess output nicely) with Tkinter. Over in tulip-land there is an demo of such an integration. On Tue, May 5, 2015 at 6:03 PM, Terry Reedy wrote: > On 5/5/2015 6:25 PM, Yury Selivanov wrote: > > Yes, there is no

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5/5/2015 6:25 PM, Yury Selivanov wrote: Yes, there is no other popular event loop for 3.4 other than asyncio, There is the tk(inter) event loop which also ships with CPython, and which is commonly used. that uses coroutines based on generators Oh ;-) Tkinter event loop is callback bas

Re: [Python-Dev] Accepting PEP 492 (async/await)

Hi, 2015-05-06 1:53 GMT+02:00 Guido van Rossum : > In order to save myself a major headache I'm hereby accepting PEP 492. Great! Congrats Yury. > I've given Yury clear instructions to focus on how to proceed -- he's to > work with another core dev on getting the implementation ready in time for

Re: [Python-Dev] Accepting PEP 492 (async/await)

On 2015-05-05 7:53 PM, Guido van Rossum wrote: Everybody, In order to save myself a major headache I'm hereby accepting PEP 492. I've been following Yury's efforts carefully and I am fully confident that we're doing the right thing here. There is only so much effort we can put into clarifying t

Re: [Python-Dev] Accepting PEP 492 (async/await)

Congratulations, Yury! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 492 (async/await)

I totally forgot to publicly congratulate Yury on this PEP. He's put a huge effort into writing the PEP and the implementation and managing the discussion, first on python-ideas, later on python-dev. Congrats, Yury! And thanks for your efforts. Godspeed. On Tue, May 5, 2015 at 4:53 PM, Guido van R

[Python-Dev] Accepting PEP 492 (async/await)

Everybody, In order to save myself a major headache I'm hereby accepting PEP 492. I've been following Yury's efforts carefully and I am fully confident that we're doing the right thing here. There is only so much effort we can put into clarifying terminology and explaining coroutines. Somebody sh

Re: [Python-Dev] PEP 492: async/await in Python; version 5

I wonder if you could look at Tkinter for a very different view of the world. While there are ways to integrate socket I/O with the Tcl/Tk event loop, the typical Python app using Tkinter probably moves network I/O (if it has any) to a separate thread, and ignores the delays of disk-based I/O (beca

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5 May 2015 at 23:28, Guido van Rossum wrote: >> At this point, *all* I'm thinking of is a toy. So, an implementation >> somewhat parallel to asyncio, but where the event loop just passes >> control to the next task - so no IO multiplexing. Essentially Greg >> Ewing's example up to, but not incl

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5 May 2015 at 23:25, Yury Selivanov wrote: >> Note that I don't have a problem with there being no existing >> implementation other than asyncio. I'd just like it if we could be >> clear over exactly what we mean when we say "the PEP is not tied to >> asyncio". > > Well, "the PEP is not tied to

Re: [Python-Dev] PEP 492: Please mention the Event Loop

Jim, On 2015-05-05 5:09 PM, Jim J. Jewett wrote: On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote: It's not as complicated as it seems when you realize there is an event loop driving everything (which people have been leaving out of the conversation since it doesn't tie into the syntax direc

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On Tue, May 5, 2015 at 2:40 PM, Paul Moore wrote: > On 5 May 2015 at 22:25, Guido van Rossum wrote: > [Paul:] > >> I'd be interested in writing, for instructional purposes, a toy but > >> complete event loop. But I'm *not* really interested in trying to > >> reverse engineer the required interf

Re: [Python-Dev] PEP 492: async/await in Python; version 5

Paul, On 2015-05-05 5:54 PM, Paul Moore wrote: On 5 May 2015 at 22:38, Yury Selivanov wrote: n 2015-05-05 5:01 PM, Paul Moore wrote: On 5 May 2015 at 21:00, Yury Selivanov wrote: On 2015-05-05 3:40 PM, Jim J. Jewett wrote: On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated P

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Tue, May 5, 2015 at 3:01 PM, Nathaniel Smith wrote: On May 5, 2015 2:14 PM, "Guido van Rossum" wrote: > > > > In the PEP 492 world, these concepts map as follows: > > > > - Future translates to "something with an __await__ method" (and asyncio > Futures are trivially made compliant by definin

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On May 5, 2015 2:14 PM, "Guido van Rossum" wrote: > > In the PEP 492 world, these concepts map as follows: > > - Future translates to "something with an __await__ method" (and asyncio Futures are trivially made compliant by defining Future.__await__ as an alias for Future.__iter__); > > - "asyncio

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5 May 2015 at 22:38, Yury Selivanov wrote: > n 2015-05-05 5:01 PM, Paul Moore wrote: >> >> On 5 May 2015 at 21:00, Yury Selivanov wrote: >>> >>> On 2015-05-05 3:40 PM, Jim J. Jewett wrote: On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. Where

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Tue, May 5, 2015 at 2:29 PM, Paul Moore wrote: > On 5 May 2015 at 22:12, Guido van Rossum wrote: > > I apologize for the confusing documentation. We need more help from > > qualified tech writers! Writing PEP 3156 was a huge undertaking for me; > > after that I was exhausted and did not want

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 2015-05-05 5:31 PM, Jim J. Jewett wrote: Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote: >As for terminology, I view this discussion differently. It's >not about the technical details (Python has asymmetric >coroutines, that's it), but rather on how to disambiguate >coroutines impleme

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5 May 2015 at 22:25, Guido van Rossum wrote: >> I'd be interested in writing, for instructional purposes, a toy but >> complete event loop. But I'm *not* really interested in trying to >> reverse engineer the required interface. > > This is a great idea. What kind of application do you have in

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 2015-05-05 5:01 PM, Paul Moore wrote: On 5 May 2015 at 21:00, Yury Selivanov wrote: On 2015-05-05 3:40 PM, Jim J. Jewett wrote: On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. Where are the following over-simplifications wrong? (1) The PEP is intended for use (a

Re: [Python-Dev] PEP 492: Please mention the Event Loop

On 5 May 2015 at 22:09, Jim J. Jewett wrote: > Proposed second paragraph of the abstract: > > This PEP assumes that the asynchronous tasks are scheduled and > coordinated by an Event Loop similar to that of stdlib module > asyncio.events.AbstractEventLoop. While the PEP is not tied to > any speci

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote: > As for terminology, I view this discussion differently. It's > not about the technical details (Python has asymmetric > coroutines, that's it), but rather on how to disambiguate > coroutines implemented with generators and yield-from, from >

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 5 May 2015 at 22:12, Guido van Rossum wrote: > I apologize for the confusing documentation. We need more help from > qualified tech writers! Writing PEP 3156 was a huge undertaking for me; > after that I was exhausted and did not want to take on writing the end user > documentation as well, so

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On Tue, May 5, 2015 at 2:01 PM, Paul Moore wrote: > On 5 May 2015 at 21:00, Yury Selivanov wrote: > > On 2015-05-05 3:40 PM, Jim J. Jewett wrote: > >> > >> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated > PEP492. > >> > >> Where are the following over-simplifications wrong? >

Re: [Python-Dev] Sub-claasing pathlib.Path seems impossible

In article , Christophe Bal wrote: > In this post > oes-not-work/29854141#29854141>, > I have noticed a problem with the following code. [...] > This breaks the sub-classing from Python point of view. In the post >

[Python-Dev] PEP 492: Please mention the Event Loop

On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote: > It's not as > complicated as it seems when you realize there is an event loop driving > everything (which people have been leaving out of the conversation since it > doesn't tie into the syntax directly). Another reason people don't realize i

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 5 May 2015 at 21:57, Guido van Rossum wrote: > On Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote: >> >> It's very hard to separate coroutines from asyncio, because there's no >> other example (not even a toy one) to reason about. > > What about Greg Ewing's example? > http://www.cosc.canterbury

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Tue, May 5, 2015 at 1:44 PM, Paul Moore wrote: > [Guido] > > The run_in_executor call is not callback-based -- the confusion probably > > stems from the name of the function argument ('callback'). It actually > > returns a Future representing the result (or error) of an operation, > where > >

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 5 May 2015 at 21:00, Yury Selivanov wrote: > On 2015-05-05 3:40 PM, Jim J. Jewett wrote: >> >> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. >> >> Where are the following over-simplifications wrong? >> >> (1) The PEP is intended for use (almost exclusively) with >>

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 2015-05-05 4:39 PM, Paul Moore wrote: Is there anyone who feels they could write a stripped down but working example of a valid Python event loop*without* the asyncio aspects? Or is that what David Beazley's talk does? Yes, in David's talk, where he starts to use 'yield from' you can simply

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Tue, May 5, 2015 at 1:39 PM, Paul Moore wrote: > It's very hard to separate coroutines from asyncio, because there's no > other example (not even a toy one) to reason about. > What about Greg Ewing's example? http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Sc

Re: [Python-Dev] PEP 492: async/await in Python; version 5

One small clarification: On Tue, May 5, 2015 at 12:40 PM, Jim J. Jewett wrote: > [...] but I don't understand how this limitation works with things like a > per-line file iterator that might need to wait for the file to > be initially opened. > Note that PEP 492 makes it syntactically impossib

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Jumping in to correct one fact. On Tue, May 5, 2015 at 12:44 PM, Brett Cannon wrote: > > On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote: > >> Well, twisted always had defer_to_thread. Asyncio has run_in_executor, >> but that seems to be callback-based rather than coroutine-based? >> > > Yep. >

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 5 May 2015 at 21:38, Guido van Rossum wrote: > Jumping in to correct one fact. > > On Tue, May 5, 2015 at 12:44 PM, Brett Cannon wrote: >> >> >> On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote: >>> >>> Well, twisted always had defer_to_thread. Asyncio has run_in_executor, >>> but that seems t

Re: [Python-Dev] PEP 492: async/await in Python; version 4

(Yury gave similar responses, so (a) I'll just respond here, and (b) it's encouraging that you both responded so quickly with the same message) On 5 May 2015 at 20:44, Brett Cannon wrote: >> That's not to say that everything needs to be beginner-friendly, but >> it *does* mean that it's hard for

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On May 5, 2015 12:40 PM, "Jim J. Jewett" wrote: > > > On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. > > Where are the following over-simplifications wrong? > [...snip...] > > [Note that the actual PEP uses iteration over the results of a new > __await__ magic method, ra

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On 2015-05-05 3:40 PM, Jim J. Jewett wrote: On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. Where are the following over-simplifications wrong? (1) The PEP is intended for use (almost exclusively) with asychronous IO and a scheduler such as the asynchio event loop.

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Paul, On 2015-05-05 3:14 PM, Paul Moore wrote: On 5 May 2015 at 19:25, Yury Selivanov wrote: On 2015-05-05 7:27 AM, Wolfgang wrote: Even the discussion on python-dev suggests there is some time needed to finalize all this. I'd say that: 80% of the recent discussion of the PEP is about termi

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On Tue, May 5, 2015 at 3:14 PM Paul Moore wrote: > On 5 May 2015 at 19:25, Yury Selivanov wrote: > > On 2015-05-05 7:27 AM, Wolfgang wrote: > >> Even the discussion on python-dev suggests there is some time needed > >> to finalize all this. > > > > I'd say that: > > > > 80% of the recent discuss

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. Where are the following over-simplifications wrong? (1) The PEP is intended for use (almost exclusively) with asychronous IO and a scheduler such as the asynchio event loop. (2) The new syntax is intended to make it eas

Re: [Python-Dev] PEP 492: What is the real goal?

On Tue, May 5, 2015 at 9:48 AM, Yury Selivanov wrote: > Hi Oscar, > > I've updated the PEP with some fixes of the terminology: > https://hg.python.org/peps/rev/f156b272f860 > > I still think that 'coroutine functions' and 'coroutines' > is a better pair than 'async functions' and 'coroutines'. >

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 5 May 2015 at 19:25, Yury Selivanov wrote: > On 2015-05-05 7:27 AM, Wolfgang wrote: >> Even the discussion on python-dev suggests there is some time needed >> to finalize all this. > > I'd say that: > > 80% of the recent discussion of the PEP is about terminology. > 10% is about whether we shou

Re: [Python-Dev] ABCs - Re: PEP 492: async/await in Python; version 4

On Mon, May 4, 2015 at 10:35 AM, Jim J. Jewett wrote: > Which reminds me ... *should* the "await" keyword work with any future, > or is it really intentionally restricted to use with a single library > module and 3rd party replacements? > You can make any Future type work with await by adding an

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Hi Wolfgang, On 2015-05-05 7:27 AM, Wolfgang wrote: Hi, [..] Even the discussion on python-dev suggests there is some time needed to finalize all this. I'd say that: 80% of the recent discussion of the PEP is about terminology. 10% is about whether we should have __future__ import or not.

Re: [Python-Dev] PEP 492: What is the real goal?

Hi Oscar, I've updated the PEP with some fixes of the terminology: https://hg.python.org/peps/rev/f156b272f860 I still think that 'coroutine functions' and 'coroutines' is a better pair than 'async functions' and 'coroutines'. First, it's similar to existing terminology for generators. Second,

[Python-Dev] PEP 492: async/await in Python; version 5

Hi python-dev, Updated version of the PEP is below. Quick summary of changes: 1. set_coroutine_wrapper and get_coroutine_wrapper functions are now thread-specific (like settrace etc). 2. Updated Abstract & Rationale sections. 3. RuntimeWarning is always raised when a coroutine wasn't awaited

Re: [Python-Dev] PEP 492: What is the real goal?

On 30 April 2015 at 09:50, Arnaud Delobelle wrote: >> >> I'm flexible about how we name 'async def' functions. I like >> to call them "coroutines", because that's what they are, and >> that's how asyncio calls them. It's also convenient to use >> 'coroutine-object' to explain what is the result

Re: [Python-Dev] PEP 492: What is the real goal?

On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote: >>> Yes, you can't use 'yield from' in __exit__/__enter__ >>> in current Python. >> What do you mean by "can't use"? > It probably executed without errors, but it didn't run the > generators. True. But it did return the one created by __

Re: [Python-Dev] PEP 492: async/await in Python; version 4

tds333 gmail.com gmail.com> writes: > > Hi, > > still watching progress here. Read all posts and changes. > > Everything improved and I know it is a lot of work. Thx for doing this. > > But I still think this PEP goes to far. > > [...] > > We forget to address the major problems here. How

[Python-Dev] PEP 492: async/await in Python; version 4

Hi, still watching progress here. Read all posts and changes. Everything improved and I know it is a lot of work. Thx for doing this. But I still think this PEP goes to far. 1. To have "native coroutines" and await, __await__ is very good and useful. Also for beginners to see and mark coroutine

[Python-Dev] PEP 492: async/await in Python; version 4

Hi, still watching progress here. Read all posts and changes. Everything improved and I know it is a lot of work. Thx for doing this. But I still think this PEP goes to far. 1. To have "native coroutines" and await, __await__ is very good and useful. Also for beginners to see and mark coroutine