Re: [python-tulip] Re: change yield x to yield From(x) in Trollius?

On 1/23/2014, 4:42 PM, Victor Stinner wrote: 2014/1/23 Yury Selivanov yselivanov...@gmail.com: What would be From(x)? A dummy function just returning x? def From(x): return x In production yes, but I would also suggest that in debug mode it should return a wrapper object, that is checked

[python-tulip] Event loop error handler

As discussed with Guido in issue #80 (https://code.google.com/p/tulip/issues/detail?id=80), I'm proposing a strawman design for having a user definable event loop handler for unhandled exceptions. Two new API points: - loop.set_exception_handler(callback) Sets 'callback' as a new

Re: [python-tulip] Event loop error handler

On 2/6/2014, 1:24 PM, Guido van Rossum wrote: On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov yselivanov...@gmail.comwrote: As discussed with Guido in issue #80 (https://code.google.com/p/tulip/issues/detail?id=80), I'm proposing a strawman design for having a user definable event loop handler

Re: [python-tulip] Event loop error handler

On 2/6/2014, 3:44 PM, Guido van Rossum wrote: [snip] I'm not sure. The default exception handler may, over time, develop some useful custom behavior, and it's not like its signature is very complicated or using it is fraught with problems. So I don't see much downside to letting users call

Re: [python-tulip] Event loop error handler

On 2/6/2014, 5:34 PM, Victor Stinner wrote: Install an handler for unhandled exceptions is not something new: there is already sys.displayhook and sys.excepthook. I'm not sure that it's useful to get the default handler. Just give access to the current handler. So when you setup a new handler,

Re: [python-tulip] Event loop error handler

On 2/6/2014, 11:02 PM, Guido van Rossum wrote: On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanovyselivanov...@gmail.comwrote: A question to you and Guido: should the callback receive three arguments: loop, exception, and context, where context is a namedtuple (so we can add new fields to it in

Re: [python-tulip] Event loop error handler

On 2/7/2014, 3:52 PM, Guido van Rossum wrote: Can't you add a reference to the loop to the tb logger object? The loop should outlive any futures anyway (since the future has a reference to the loop) and it shouldn't be a ref cycle. Sure. Another question: logger.exception is also used in: -

Re: [python-tulip] Event loop error handler

On 2/7/2014, 4:47 PM, Guido van Rossum wrote: And one more, aesthetic question: the currently agreed on signature of exception handlers is '(loop, context)'. I have a method BaseEventLoop.default_exception_handler(self, context), but when the method is bound, its signature is just '(context)',

Re: [python-tulip] Event loop error handler

On 2/7/2014, 4:47 PM, Guido van Rossum wrote: On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanovyselivanov...@gmail.comwrote: On 2/7/2014, 3:52 PM, Guido van Rossum wrote: Can't you add a reference to the loop to the tb logger object? The loop should outlive any futures anyway (since the future

Re: [python-tulip] aiohttp and classical web frameworks

On 2/18/2014, 4:44 AM, chrysn wrote: technically, i added an `asyncio.events.current_context` global dictionary, made all `asyncio.events.Handle` objects copy that on creation, and made the base event loop set the context dictionary of the handle to be executed globally, both serving as a

Re: [python-tulip] Re: Tulip third-party projects and Trollius

On 2/20/2014, 12:54 PM, Guido van Rossum wrote: The source transformation route has not been very popular with Python 2 vs. 3 porting projects. It's not popular, but nevertheless, many use it just fine. I wonder if it would be possible (using asyncio internals) to write a From() function

Re: [python-tulip] New Trollius documentation

On 2/21/2014, 5:47 AM, Victor Stinner wrote: [snip] By the way, it may be nice to copy the asyncio documentation in the Tulip project as I remember that changes should also be documented (recent examples: the documentation of the UNIX and exception handler methods was written after adding the

Re: [python-tulip] New Trollius documentation

On 2/21/2014, 2:22 PM, Guido van Rossum wrote: I don't actually understand the proposal. :-( Victor proposes to fix missing docstrings (and some '''XXX''') in the asyncio code, by copying/ adapting the refined text from cpython docs. Yury

Re: [python-tulip] 'global name \'s\' is not defined' : any suggestions or hints?

Marco, The problem is on the line number 82 of your script: yield From(s.get( ... )) where 's' is undefined. Tracing was easy when I added the following code import traceback print(traceback.format_exc()) before your print('...', url, 'has error', repr(str(exc))) Now, this list is

Re: [python-tulip] Tkinter + asyncio?

Hi Skip, Take a look at this library: https://github.com/harvimt/quamash#usage It's for the QT framework, but it might be a good example of how to start the Gtk integration. Yury On 2015-05-08 11:30 AM, Skip Montanaro wrote: Are there examples of using asyncio to linearize the logic of GUI

Re: [python-tulip] Moving Tulip repo to GitHub

? On Apr 10, 2015, at 2:49 PM, Guido van Rossum gu...@python.org wrote: The migration has now completed. Please point your repos to https://github.com/gvanrossum/tulip ! On Wed, Apr 8, 2015 at 12:13 PM, Alexander Shorin kxe...@gmail.com wrote: On Wed, Apr 8, 2015 at 10:11 PM, Yury Selivanov

[python-tulip] Re: Moving Tulip repo to GitHub

Hi Guido, How will we migrate issues? Just recreate them on guthub, or abandon and start from scratch? I was going to continue discussion on https://code.google.com/p/tulip/issues/detail?id=208 Yury On Wednesday, April 8, 2015 at 1:32:40 PM UTC-4, Guido van Rossum wrote: Because Google

Re: [python-tulip] Re: Moving Tulip repo to GitHub

, Apr 8, 2015 at 12:00 PM, Yury Selivanov yseliva...@gmail.com wrote: Hi Guido, How will we migrate issues? Just recreate them on guthub, or abandon and start from scratch? I was going to continue discussion on https://code.google.com/p/tulip/issues/detail?id=208 Yury On Wednesday

Re: [python-tulip] Add timeout to StreamReader read methods

On 2015-09-03 2:01 PM, Yury Selivanov wrote: On 2015-09-03 11:04 AM, Victor Stinner wrote: Hi, I proposed a patch to add timeout to StreamReader read methods: http://bugs.python.org/issue23236 I'm +1, but there are some subtleties that I want to better understand: The idea is to reset

Re: [python-tulip] Please try with the patch from Issue 25593

> On Nov 19, 2015, at 1:01 PM, Aymeric Augustin > wrote: > > Hello, > > I understand the backwards-compatibility concerns. However I have to say that > the pattern: > > loop.call_soon(loop.stop) > loop.run_forever() > > seems much easier to

Re: [python-tulip] Coverage.py support for await and yield-from: how should it work?

Hi Ned, On 2016-01-11 7:39 PM, Ned Batchelder wrote: [...] What would you prefer? My understanding is that "await" behaves the same, so I'm assuming the same decision would apply there. I haven't used coverage with generator-based coroutines, but here's my understanding on how it should

Re: [python-tulip] asyncio lost udp packets

On 2016-06-09 9:50 AM, vpavesi wrote: I do have two threads, main to handle datagram_received add to queue and another to read from queue and handle tcp/json. Why are you using threads? Can you do everything in one thread and check how everything is working? Yury

Re: [python-tulip] Re: FrameworkBenchmarks Round 11 results are available

Hi Ludovic, I’m usually highly sceptical about any network benchmarks over localhost. I’d suggest you to rerun your benchmarks using two different machines connected over a gigabit network. Please make sure that your server process loads the CPU 100%, and ideally you should use several

[python-tulip] uvloop

Hi, Please check out a new asyncio event loop implementation uvloop. Here's a blog post about it: http://magic.io/blog/uvloop-make-python-networking-great-again/ Thanks, Yury

Re: [python-tulip] Re: uvloop

On 2016-05-04 12:35 AM, Justin Mayfield wrote: Wow. Testing with my asyncio libs now.. Great! Please share your results! Yury

Re: [python-tulip] uvloop

On 2016-05-04 3:46 AM, Stefan Scherfke wrote: Hi Yury, Am 2016-05-04 um 00:43 schrieb Yury Selivanov <yselivanov...@gmail.com>: Hi, Please check out a new asyncio event loop implementation uvloop. Here's a blog post about it: http://magic.io/blog/uvloop-make-python-networking-great

Re: [python-tulip] uvloop

On 2016-05-03 7:50 PM, Gustavo Carneiro wrote: Really good work! Question: could the asyncio-streams results be affected by the performance bottleneck found (and fixed) by Коренберг Марк? https://github.com/python/asyncio/pull/339 Maybe, we'll see! It would be interesting if you could

Re: [python-tulip] Re: Notes on writing a new official asyncio tutorial

I recommend to create a new github org -- aio-docs. Let's not bother with github/python org at all. Sent from my iPhone > On Jul 22, 2016, at 3:34 PM, Andrew Svetlov wrote: > > I think https://github.com/python/asyncio-doc with dedicated team for giving > write

Re: [python-tulip] Explicit vs Implicit event loop

On 2016-11-08 11:07 AM, Martin Richard wrote: - the feature is left as it is: a library author should no longer have to deal with the loop from a coroutine/a callback, and this is how asyncio libraries should be written. ^- this. To add to what Guido said, I think we should promote

Re: [python-tulip] Explicit vs Implicit event loop

Martin, > On Nov 8, 2016, at 1:39 PM, Martin Richard wrote: > > I fully agree about coroutines, one thing though: I often see functions > returning awaitables documented as "coroutines", and I see that as a problem > since it gives the assumption that it won't be

Re: [python-tulip] inspect.iscoroutine only works for "native" coros

Introspection functions from the inspect module are designed for native types. Introspection functions from asyncio are designed for what asyncio treats as coroutines. Consider this example: @asyncio.coroutine def coro(): print(‘hello’) ‘asyncio.iscoroutinefunction' will return ‘True' for

Re: [python-tulip] inspect.iscoroutine only works for "native" coros

On 2016-11-08 12:47 AM, Justin Mayfield wrote: That's quite surprising to me too, BTW. I was focused on generator vs `async def ...` coros and hadn't even tried the legacy decorator. Would it be possible for asyncio code to be altered in a way that produces awaitables which conform with

Re: [python-tulip] Curio

Imran, I don’t think this is a productive discussion. FWIW it's possible to implement all of Curio’s APIs on top of current asyncio: there are no fundamental blockers to that. If you think that Curio is better in some regards, please feel free to post concrete proposals to

Re: [python-tulip] Throttling connection limit of loop.create_server based servers

Hi, No, I don’t think we have an API for that. I suppose you can make a PR (or open an issue) at github.com/python/asyncio proposing to add `pause_serving()`/`resume_serving()`. I’m afraid we aren’t going to add them until 3.7, since Python 3.6 is in feature freeze mode now. Yury > On Oct

Re: [python-tulip] Curio

> On Oct 24, 2016, at 12:24 PM, Xavier Combelle > wrote: > > - the run function > - the await, async keyword > The other api are copy paste to the synchrone ones Yes, this is something that has to be fixed in asyncio docs. Protocols/transports are advanced low

Re: [python-tulip] Curio

> On Oct 24, 2016, at 12:38 PM, Xavier Combelle > wrote: > > >> Yes, this is something that has to be fixed in asyncio docs. >> Protocols/transports are advanced low level concepts, you don’t need to even >> know about them to use asyncio programs. I’ll try to

Re: [python-tulip] inspect.iscoroutine only works for "native" coros

Hi Justin, > On Nov 10, 2016, at 6:59 PM, Justin Mayfield wrote: > > Thank you for your thoughtful and informative reply Yury. > > I'm mostly convinced that doc updates (to which you have already made > several) informing users of potential peril is the safest thing to do.

Re: [python-tulip] RabbitMQ RPC problem with asyncio

On 2016-01-18 2:50 PM, Charles-François Natali wrote: No caveats, actually I think this should be the default (that's the asyncio will set it by default in 3.6. Yury

Re: [python-tulip] Python 3.6b2 will have C implemented Future

3.6 + C Future + C Task Python 3.6 + Py Future + Py Task Yury > On Nov 18, 2016, at 6:02 PM, Yury Selivanov <yseliva...@gmail.com> wrote: > > >> On Nov 18, 2016, at 5:53 PM, Luca Sbardella <luca.sbarde...@gmail.com> wrote: >> >> But tests taking 1.48

Re: [python-tulip] Python 3.6b2 will have C implemented Future

> On Nov 18, 2016, at 5:53 PM, Luca Sbardella wrote: > > But tests taking 1.48 longer to run on average! > Anything I should know about 3.6 and performance? > That shouldn’t happen. Are you sure you aren’t running them in debug mode? Try to comment out imports of

Re: [python-tulip] Discussion thread for: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

> On Oct 30, 2016, at 2:42 PM, Guido van Rossum <gu...@python.org> wrote: > > On Sun, Oct 30, 2016 at 11:27 AM, Yury Selivanov <yseliva...@gmail.com> wrote: >> >>> On Oct 30, 2016, at 1:58 PM, Guido van Rossum <gu...@python.org> wrote: >>>

Re: [python-tulip] Discussion thread for: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

> On Oct 30, 2016, at 3:02 PM, Yury Selivanov <yseliva...@gmail.com> wrote: > > I’ve just looked through events.py. I think we may only need to add > “asyncio.run_in_executor(func)”, and maybe “asyncio.create_task(coroutine)” > functions. With that it should be po

Re: [python-tulip] Explicit vs Implicit event loop

> On Oct 31, 2016, at 2:43 PM, Guido van Rossum wrote: > > Thanks! We can fix this in 3.6b4. Awesome! I’ll reopen that PR in a couple of days. Thank you, Yury

Re: [python-tulip] Explicit vs Implicit event loop

Guido, I’m with Andrew on this one. > On Oct 31, 2016, at 10:27 AM, Guido van Rossum wrote: > > I would suggest different guidelines for libraries than for > applications: Libraries should be robust and always store their own > loop. This is how asyncio itself works and how

Re: [python-tulip] Explicit vs Implicit event loop

> On Nov 1, 2016, at 10:46 AM, Andrew Svetlov wrote: > > The same problem is present in asyncio classes itself: Lock, Queue, streams > could be created with global life time and they are will hang if used from > different loop. Once we fix get_event_loop we can

Re: [python-tulip] Discussion thread for: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

I think there are some valid, as well as not so valid, points in that blog post. One thing for sure: we need to restructure the documentation. Anyways, I’ll try to go through the blog post in detail and create issues to address some things. Yury > On Oct 30, 2016, at 1:29 PM, Justin

Re: [python-tulip] Discussion thread for: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

> On Oct 30, 2016, at 1:58 PM, Guido van Rossum wrote: > > Regarding the documentation, I doubt we can get it in shape just by > filing issues. We should really just have a tutorial written by > someone with a good understanding of asyncio and writing skills. Yeah, I agree.

Re: [python-tulip] multiprocessing issue with python 3.6

> > Is that what I'm supposed to do? Or is there a better way? > > A better was is to never fork or spawn multiprocessing.Process from a running > coroutine. > > right, so if the forking is not in a coroutine it may work?!?! It should, because the running loop is set only when the loop is

Re: [python-tulip] No tracebacks when running from run_until_complete

Hi, Can you try Python 3.6 rc1? This is likely related to http://bugs.python.org/issue28843 Yury > On Dec 16, 2016, at 12:44 PM, Carlo Pires wrote: > > Hi, > > I'm starting with asyncio and python3.6 (using Python 3.6.0b4). > > See this snippet: > > import asyncio

Re: [python-tulip] No tracebacks when running from run_until_complete

Python-3.6.0rc1/Lib/test/regrtest.py", line > 46 in _main > File "/home/carlopires/py36comp/Python-3.6.0rc1/Lib/test/regrtest.py", line > 50 in > File "/home/carlopires/py36comp/Python-3.6.0rc1/Lib/runpy.py", line 85 in > _run_code > File "

Re: [python-tulip] multiprocessing issue with python 3.6

> On Dec 9, 2016, at 5:57 AM, Luca Sbardella wrote: > > Hi, > > I'm trying to run pulsar in multiprocessing mode (using the multiprocessing > module to create processes rather than asyncio subprocess). > However, in python 3.6 I have a small problem. > When the new

Re: [python-tulip] asyncio, datagram transports and recvmsg

Hi, On Sep 24, 2018, 11:27 PM -0400, chrysn , wrote: [..] > * Export something like loop._add_reader as part of the public > loop interface. We already have them as part of the public API:  https://docs.python.org/3/library/asyncio-eventloop.html#watching-file-descriptors Would they work for

Re: [python-tulip] Status of TaskGroup or something like it?

Hi Justin, Yes, we want to have TaskGroups in asyncio, and the only reason we didn't add them to Python 3.8 is that we also need to support ExceptionGroups (or MultiErrors).  Nathaniel and I plan to start working on that. Here's am implementation of TaskGroups that I created for EdgeDB