On 1/23/2014, 4:33 PM, Victor Stinner wrote:
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 in your
trampoline.
And in general, it's a great advic
On 1/23/2014, 4:42 PM, Victor Stinner wrote:
2014/1/23 Yury Selivanov :
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 in your
trampoline
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 unhandl
On 2/6/2014, 1:24 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 8:53 AM, Yury Selivanov wrote:
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 unha
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 loo
On 2/6/2014, 5:06 PM, Victor Stinner wrote:
Hi,
2014-02-06 17:53 GMT+01:00 Yury Selivanov :
I'm proposing a strawman design for having a user definable event loop
handler for unhandled exceptions.
With my short experience of asyncio, I can say that it's a pain to
reconnect an
On 2/6/2014, 5:10 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 1:15 PM, Yury Selivanov wrote:
So let me reiterate on the proposed design:
This design looks good to me.
loop.set_exception_handler(handler)
Sets 'handler' as a new unhandled exceptions handler.
I&#x
On 2/6/2014, 5:46 PM, Victor Stinner wrote:
However, I'm not sure how passing the future/handle to the
handler may help. You have the name of the failed callback
in the traceback of the exception. And, in many places all
you have is just the failed callback function, and no
related future or t
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
On 2/6/2014, 11:02 PM, Guido van Rossum wrote:
On Thu, Feb 6, 2014 at 2:54 PM, Yury Selivanovwrote:
>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 future releases). For
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:
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 '(contex
On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanovwrote:
>
>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
On 2/13/2014, 2:39 PM, Guido van Rossum wrote:
Having a new debug flag on the event loop that defaults to False sounds
like a fine solution (I don't like the existing _DEBUG thing much anyway).
Please make getting and setting it methods (every event loop API is a
method). Perhaps it ought to be
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 templa
On 2/19/2014, 10:55 AM, Guido van Rossum wrote:
Because that would require duplicating the logic in
create_datagram_endpoint(), which is totally separate (all the way down to
the I/O callbacks).
Exactly. I was hesitant to do that myself because my experience
with UDP is fairly limited.
Yury
Victor,
On 2/20/2014, 6:33 AM, Victor Stinner wrote:
Hi,
Tulip uses "yield from" whereas this instruction is new in Python 3.3
and cannot be used on Python 2, so Trollius uses "yield" instead. The
problem is that third-party projects like aiohttp uses "yield from".
On the OpenStack mailing lis
On 2/20/2014, 11:42 AM, Antoine Pitrou wrote:
On Thu, 20 Feb 2014 11:30:21 -0500
Yury Selivanov
wrote:
Cons:
- I don't see any, really. 'From' wrappers will have a small
performance cost, but I'm sure it will be negligible.
From what I understand, you still can't w
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 that
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 fu
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
Victor,
I think the design should be a bit different.
Instead of passing 'exc_info', we can pass 'traceback' key, like
in the snippet below:
self.call_exception_handler({
'message': 'socket.accept() out of system resource',
'exception': exc,
'traceback': sys.exc_info
On 2/25/2014, 12:04 PM, Victor Stinner wrote:
2014-02-25 17:26 GMT+01:00 Yury Selivanov :
Victor,
I think the design should be a bit different.
Instead of passing 'exc_info', we can pass 'traceback' key, like
in the snippet below:
Why not calling sys.exc_info() in Tulip
Great!
Yury
On 2/25/2014, 12:19 PM, Victor Stinner wrote:
2014-02-25 18:12 GMT+01:00 Yury Selivanov :
BTW, one more option:
call_exception_handler can detect if context['exception']
is missing '__traceback__' and it is python2, and call
'sys.exc_info()[2]' itse
On 2/25/2014, 2:33 PM, Guido van Rossum wrote:
On Tue, Feb 25, 2014 at 9:00 AM, Victor Stinner wrote:
- replace "{} {}" with "{0} {1}"
This specific case we can fix by using named placeholders,
i.e. instead if
'{} {!r}'.format(spam_expr, ham_expr)
we can use
'{spam} {ham!r}'.format
On 2014-02-27, 1:02 PM, Victor Stinner wrote:
The activate() method of the _TracebackLogger is never executed, the
_TracebackLogger is part of a reference cycle and cannot be collected
by the garbage collector, and the unhandled exception is not logged.
Why is it never executed? There's this li
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
Victor,
It's such a great idea! Congrats.
Maybe we should include aiotest to the asyncio package/python stdlib?
This way it will always stay in sync and up to date with asyncio APIs,
and will be something that everybody who implements asyncio-compatible
loops will use.
Yury
On 2014-12-12,
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 co
ted fully.
>
> On Wed, Apr 8, 2015 at 12:00 PM, Yury Selivanov 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
"Donald Stufft" wrote:
>> I just noticed this, would it make sense to put it under github.com/python ?
>>
>>
>>> On Apr 10, 2015, at 2:49 PM, Guido van Rossum wrote:
>>>
>>> The migration has now completed. Please point your repos to
>
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
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 the timeout each time we receive new data. It is
l
On 2015-09-03 1:11 PM, Guido van Rossum wrote:
I agree (unsurprisingly since it seems I brought it up in the first
place :-). I wonder if the parameter name should be other than
timeout, since it may surprise people that a readline() with a timeout
of 5 secs can take longer than 5 secs to compl
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 rese
> 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 understand and more logical than:
>
>
> On Dec 10, 2015, at 4:47 AM, Vincent Michel wrote:
>
> > Does setting PYTHONASYNCIODEBUG=1 complain about these mistakes?
>
> No it doesn't, unless the other loop is also running but that's only because
> `asyncio.sleep` calls `future._loop.call_later` before yielding the future.
> `_check_
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 beh
Hi Imran,
On 2016-01-31 6:51 AM, Imran Geriskovan wrote:
Currently class instances can not
directly be created asyncronously.
Yes, there are other means for async
creation. (As we have discussed before,
factories, __new__ is a coroutine, etc)
However, having all creation logic, under
the class
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 proces
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
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 c
On 2016-05-04 12:35 AM, Justin Mayfield wrote:
Wow. Testing with my asyncio libs now..
Great! Please share your results!
Yury
On 2016-05-04 3:46 AM, Stefan Scherfke wrote:
Hi Yury,
Am 2016-05-04 um 00:43 schrieb Yury Selivanov :
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
very
Hi Ludovic,
> On May 5, 2016, at 5:23 PM, Ludovic Gasc wrote:
>
> Hey Yury,
>
> Thanks a lot for this amazing job, it's awesome :-)
> Theses results are beyond my expectations, it was my hope when I've tried to
> benchmark aiouv.
Thanks!
[..]
> However, at least to me, aiohttp.web has a very
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
> On Jul 21, 2016, at 3:13 PM, Rémi Cardona wrote:
>
> IMHO the biggest missing piece is how to work with protocols: how to work
> with protocols/transports/streams internals, what the user-facing API should
> be, etc
I could actually write a tutorial on how to do that. In the meanwhile if y
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 access is preferable
>
>
>> O
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 1
> On Oct 18, 2016, at 4:10 PM, Justin Mayfield wrote:
>
> Re 3.6 freeze, This is understandable.
>
> I just wanted to make sure I wasn't missing something in the first place. I
> can submit a PR/Issue that focuses on Server.pause_serving and resume_serving
> if that's the most sensible place
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 github.com/python/a
> 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 level concepts, you don’t need
> 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 find some time to work
>> on
> On Oct 24, 2016, at 12:49 PM, Paul Sokolovsky wrote:
>
> .read() and .write() are generic methods of Python's stream interface
> ("protocol"). Sadly, Python's sockets don't implement stream interface
> natively, but require converting to a stream with .makefile() method.
> So, you can consider
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 Mayfield
> 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. I don’t want to pro
> On Oct 30, 2016, at 2:42 PM, Guido van Rossum wrote:
>
> On Sun, Oct 30, 2016 at 11:27 AM, Yury Selivanov wrote:
>>
>>> On Oct 30, 2016, at 1:58 PM, Guido van Rossum wrote:
>>>
>>> Regarding the documentation, I doubt we can get it in shape just b
> On Oct 30, 2016, at 3:02 PM, Yury Selivanov 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 possible to have almost the sa
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 aiohttp (and other
>
> 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
> 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 guard against this in debug mod
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
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 inspec
Justin,
First, thanks a lot for a detailed review of PEP 492/inspect/asyncio docs.
> On Nov 8, 2016, at 4:39 AM, Justin Mayfield wrote:
>
> Reading into these flags more, I wonder if modifications to the
> inspect.iscoroutine* functions as well as to genobject.c's finalizer are
> justified.
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
corouti
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 executed until processed by
>
On 2016-11-08 3:29 PM, Guido van Rossum wrote:
I think the problem is that it's hard to tell the difference between these
two:
async def sleep1():
await asyncio.sleep(1)
def sleep1():
return Task(asyncio.sleep(1))
since both may be documented as being a "coroutine" but the latter
r
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. So I
> won't harp
> 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 ‘_asyncio’ in futures.py a
3.6 + C Future + C Task
Python 3.6 + Py Future + Py Task
Yury
> On Nov 18, 2016, at 6:02 PM, Yury Selivanov wrote:
>
>
>> On Nov 18, 2016, at 5:53 PM, Luca Sbardella wrote:
>>
>> But tests taking 1.48 longer to run on average!
>> Anything I shou
> On Nov 18, 2016, at 6:16 PM, Luca Sbardella wrote:
>
> Running 3.6-dev from travis, currently b4+.
> No debug mode, that is an order of magnitude slower ;-)
FWIW I found that I can’t really trust the build times on travis for measuring
any kind of performance regressions. You don’t know how
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
> 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 process starts, it creates t
> > 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 runn
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
>
> async def fa():
>
egrtest.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 "/home/carlopires/py36comp
Yes, this is a bug, and looks like Task.all_tasks() has the same problem. I’ve
created a bug to track the issue: http://bugs.python.org/issue29271
Yury
> On Jan 13, 2017, at 4:12 PM, Guido van Rossum wrote:
>
> Can you file a bug in the CPython tracker for this? bugs.python.org.
>
> On Fri, Ja
I'm not sure if aiofiles is stable or not, but I would like the actual
implementation to be slightly different. aiofiles simply proxies all file IO
operations through a thread pool, but there are better alternatives in some
cases. Using a thread pool is totally fine for vanilla asyncio, but th
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 you?
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
https:/
80 matches
Mail list logo
