Re: [python-tulip] Asyncio + file logging has sense?

There's code in trio for treating the filesystem as async, and massive docs about when to use and when not. (Thanks Nathaniel!) We should consider adding that to asyncio, perhaps as a 3rd party package. On Wed, Apr 4, 2018, 01:22 INADA Naoki wrote: > You're right.

Re: [python-tulip] Implementing new eventloops

t;ronaldousso...@mac.com> wrote: > Hi, > > Is there documentation on how to implement new eventloops for asyncio? In > particular, I intend to write an eventloop implementation for a GUI library > (PyObjC). > > Ronald -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] UNIX socket and SOCK_DGRAM

wrote: > On Wednesday, February 19, 2014 at 4:55:03 PM UTC+1, 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). >> >> F

Re: [python-tulip] Strange behavior of asyncio in 3.6

; My python3.6 has version: > > $ python3.6 -VV > Python 3.6.0 (default, Dec 29 2016, 04:29:02) > [GCC 6.2.1 20161215] > > Thanks in advance, > > Alberto > > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] StreamWriter.drain cannot be called concurrently

PM UTC+3, Guido van Rossum wrote: >> >> Fair enough. I guess there is a real danger to overwhelm the socket? >> Otherwise you don't even need the drain() call. But it looks like you are >> basically logging as fast as you can, so the drain() seems important. >> > &

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

On Tue, Nov 8, 2016 at 12:43 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > > > 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(): >&

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

fine. > > I re-read this email a few times, but I still don’t fully understand the > problem you’re trying to describe. Maybe you can describe it in more > detail? > > Yury > > -- --Guido van Rossum (python.org/~guido)

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

On Mon, Oct 31, 2016 at 1:30 PM, Yury Selivanov <yseliva...@gmail.com> wrote: > Guido, > > I’m with Andrew on this one. > And the reason is the misbehavior of get_event_loop(), right? (See below.) > > On Oct 31, 2016, at 10:27 AM, Guido van Rossum <gu...@python.

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

handy but it's safe only inside > running task. > Getting the loop in global namespace may lead to very strange and cryptic > errors (most likely the next usage will just hang). > > Thoughts? -- --Guido van Rossum (python.org/~guido)

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

._exit(0) when you are ready to exit, to avoid all the silly cleanup-related errors that are trying to warn you against advanced mistakes. On Sun, Oct 30, 2016 at 3:00 PM, Donald Stufft <don...@stufft.io> wrote: > > On Oct 30, 2016, at 5:36 PM, Guido van Rossum <gu...@python.org> wro

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

d party package! --Guido > Cheers, > > Luciano > > > On Sun, Oct 30, 2016 at 5:02 PM, Yury Selivanov <yseliva...@gmail.com> wrote: >> >>> On Oct 30, 2016, at 2:42 PM, Guido van Rossum <gu...@python.org> wrote: >>> >>> On Sun, Oct 30, 2016 a

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

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: >> >> Regarding the documentation, I doubt we can get it in shape just by >> filing issues. We sho

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

>> quite a while. >> >> The blog: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/ > -- --Guido van Rossum (python.org/~guido)

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

nally I find it difficult to sympathize with many of the > arguments and have been a very happy user of modern python and asyncio for > quite a while. > > The blog: http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/ -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Curio

It might make more sense to propose carefully designed additions to asyncio that aim to fill in the gaps you've found by using curio. This should focus on API functionality; the performance is being worked on separately, and there's also uvloop. -- --Guido van Rossum (python.org/~guido)

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

listening socket but I don't see a good way >> to pause the _accept_connection handler that monitors the listening socket >> for read events. >> >> I'd be happy to implement my own logic for the back pressure using a public >> `pause_serving()`/`resume_serving()` API but

Re: [python-tulip] A mix of zip and select to iterate over multiple asynchronous iterator ?

8/2016 05:31 PM, Guido van Rossum wrote: > > You can do this using callbacks, or you can have separate loops > > You're right, look like I forgot to drop some context: my aggregation of > various asynchronous iterables should happen within a `def` (when this > `def` returns, th

Re: [python-tulip] Process + Threads + asyncio... has sense?

plexing/context switching of > "Python Threads"?) > Sorry, you are wrong. Python threads map 1:1 to OS threads. They are as real as threads come (the GIL notwithstanding). -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] A mix of zip and select to iterate over multiple asynchronous iterator ?

g my "SOON" > flag, and `wait` flag "ALL_COMPLETED" being my "PAIRED" flag (should I > rename mines ?) Question is: Am I walking the wrong way and is there a > simple way to do it I completly missed ? Or is my tool really usefull and > should be shared ? I'm too young in asyncio to juge that, so I'll listen to > you ! Bests, > > -- > Julien Palard > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] New asyncio release on PyPI?

, it looks like asyncio still has an old copy, release.py, which > doesn't support Git. > > Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Implementing a socket-connect timeout

's your concern here? Are you worried > my new _ipaddr_info() function might return an incorrect tuple that differs > from a real getaddrinfo() return value? > > On Tue, Feb 23, 2016 at 12:24 PM, Guido van Rossum <gu...@python.org> wrote: >> >> W00t! Hopefully when

Re: [python-tulip] Implementing a socket-connect timeout

W00t! Hopefully when you connect a socket it actually believes the pre-parsed address. --Guido (mobile)

Re: [python-tulip] Implementing a socket-connect timeout

mplex solution to a problem > that's going away. Humm... Do you for sure that getaddrinfo() can parse numeric IP addresses (of all flavors) faster than the Python code you wrote, barring the lock? If that's so I agree. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Who use Trollius? Should we deprecate this project?

'm > not following anymore the latest changes made in asyncio, so it became > harder for me to update Trollius. > > Trollius is a fork of the asyncio git repository. To update Trollius > to retrieve latest asyncio changes, you have to fix a lot of subtle > issues for Python 2 (Python 3 language is simpler!). > > Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Add Timeout class to asyncio

lar context manager (no __aenter__/__aexit__ required) and > works even with Python 3.3 > > I'll be happy to make a Pull Request after getting general agreement. > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Pattern for recurring events in coroutines?

eriod=300, loop=loop) > for future_trigger in clock.trigger_events: > tardiness = yield from future_trigger > # DO SOMETHING HERE > > > Before I did it this way, I had a pretty convoluted class with a method > that got called on a power state change event that then had to examine > state stored in the class manipulated by other methods. Moving the logic > into a single coroutine seemed to make things simpler to me. > > I have just noticed that I have classes each with two methods, one of > which is __init__. So I could turn them into plain coroutines now, which > is nice. I refactored extensively to get to where I am now so that's how > I ended up here. I won't try and do it while drafting this email though > as I don't have an easy way to test it will work. > > Thank you for reading this far! So what do you think? Am I insane, or is > this a sensible way to arrange things? > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] GC raise of GeneratorExit and naked except clauses

may be worth discussion from stakeholders that know way more about it than > I do. > > Cheers, > JM > > PS: I'm a bit busy this week so I may not be able to look at this again > till the weekend. > > On Mon, Dec 7, 2015 at 10:53 AM Guido van Rossum <gu...@python.org>

Re: [python-tulip] Implementing a socket-connect timeout

o when the time is right? > > > On Wednesday, December 9, 2015 at 6:05:46 PM UTC-5, A. Jesse Jiryu Davis > wrote: >> >> Done: >> >> https://github.com/python/asyncio/pull/302 >> >> On Wednesday, December 9, 2015 at 2:58:07 PM UTC-5, Guido van Rossum >&g

Re: [python-tulip] Yielding a future boud to different loop incidentally

t thread, but nothing prevents `Task._wakeup` to be > scheduled in a different loop that `Task._loop`. > > > > /Vincent > > Here’s a PR to fix this: https://github.com/python/asyncio/pull/303 > > Thanks, > Yury -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Implementing a socket-connect timeout

hole > event loop just so Motor's specific create_connection calls behave > correctly. > > 3. Back to the original proposal: add a connection timeout parameter to > create_connection. =) > > On Tuesday, December 8, 2015 at 4:30:04 PM UTC-5, Guido van Rossum wrote: > >> On Tue,

Re: [python-tulip] Yielding a future boud to different loop incidentally

e first time. But with the modification > proposed above, this example would raise the following exception instead: > > RuntimeError: a future using a different loop has been yielded > > Part of the problem is also that one might expect the current loop to be > used, while it actually default

Re: [python-tulip] Implementing a socket-connect timeout

uot; specially, or at least to prevent a slow > getaddrinfo from appearing to be a connection timeout. I haven't decided > which is the best approach, but #4 allows me flexibility. Would you like me > to write the patch or will you? > > I'm curious about #5 too, but I think that's a longer term p

Re: [python-tulip] Implementing a socket-connect timeout

gt; > https://hg.python.org/cpython/file/d2b8354e87f5/Modules/socketmodule.c#l185 > I don't know -- the list of ifdefs seems to indicate this is a generic BSD issue, which is OS X's heritage. Maybe someone can do an experiment, or review the source code used by Apple (if it's still open source)? While I agree that if this really isn't an issue we shouldn't bother with the lock, I'd also much rather be safe than sorry when it comes to races in core Python. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] GC raise of GeneratorExit and naked except clauses

d more compatible with common > save/restore patterns. > > JM > > On Friday, December 4, 2015 at 9:51:07 PM UTC-7, Guido van Rossum wrote: >> >> On Fri, Dec 4, 2015 at 11:39 AM, Justin Mayfield <too...@gmail.com> >> wrote: >> >>> Hi Guido, >>

Re: [python-tulip] GC raise of GeneratorExit and naked except clauses

self._loop.call_soon(self._call_connection_lost, None) > > File > "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py", > line 453, in call_soon > > handle = self._call_soon(callback, args) > > File > "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py", > line 462, in _call_soon > > self._check_closed() > > File > "/usr/local/Cellar/python3/3.5.0/Frameworks/Python.framework/Versions/3.5/lib/python3.5/asyncio/base_events.py", > line 289, in _check_closed > > raise RuntimeError('Event loop is closed') > > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Windows vs Linux/Mac Bug?

>> code from the picture. If things fail, it will be simpler to pinpoint >> where, and if things work, then it points to something in my code. >> >> Hopefully I will be able to get it this week and will report back with >> any findings. >> >> >

Re: [python-tulip] BitTorrent client with asyncio (Python 3.4.3)

answer Question 1), but it > doesn't seem right (since my program should be listening to incoming > connections, even before the client becomes a seeder.) > > After the client is a seeder, the program can start the server and the > handle_leecher coroutine handles incoming connections and handshakes. > Then the server runs forever and uploads pieces to the remote peers. > > Thanks. > Leslie > > > > > > -- --Guido van Rossum (python.org/~guido)

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

stop) >> loop.run_forever() >> >> seems much easier to understand and more logical than: >> >> loop.stop() >> loop.run_forever() > > > I agree. > > I think we’re trying too hard to save a broken behaviour. "loop.stop(); > loop

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

n replicating this result, all you need is to > checkout the websockets repository and run "make test". > > Best regards, > > -- > Aymeric. > > > >> On 18 nov. 2015, at 01:35, Guido van Rossum <gu...@python.org> wrote: >> >> In this issu

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

freedom an implementation has is how much of the "ready queue" (callbacks already scheduled with ``call_soon()``) it processes before stopping. I would love to hear from people who have tried this patch on various platforms. On Tue, Nov 17, 2015 at 4:35 PM, Guido van Rossum <gu.

Re: [python-tulip] Giving a break

O, random, ...? > > Regards, > Imran > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Is it me doing somethin wrong? or bug in task exception handling? (sampe code included)

>> raise RuntimeError >> finally: >> >> >> But personally I would just write >> >> >> raise RuntimeError >> >> If is a lot of code put it in a helper function. >> >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Is it me doing somethin wrong? or bug in task exception handling? (sampe code included)

e, self)) >> asyncio.futures.InvalidStateError: FINISHED: > done, defined at test_aio_exception.py:4> exception=RuntimeError('something >> bad',)> >> > > > i am sorry in advance if it is just something i don't understand at very > basic level about asyncio. > > > Regards, > > Oleg. > > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Is it me doing somethin wrong? or bug in task exception handling? (sampe code included)

t; > Anyway > Thanks! > > > On Wednesday, September 30, 2015 at 11:05:14 PM UTC-4, Guido van Rossum > wrote: >> >> You shouldn't do that. What's happening is that when task() returns the >> Task class wrapping it tries to set the Task object's result, but since >&g

Re: [python-tulip] SSL protocol bug.

attempts and other sorts of weird network > issues. ) > > > > On Saturday, September 19, 2015 at 11:39:43 PM UTC-4, Guido van Rossum > wrote: >> >> You should try to figure out first why the connection is lost. Perhaps an >> error message is being logged somewher

Re: [python-tulip] SSL protocol bug.

manages to set None to > self._transport. > > and whole proto just thinks it finished a handshake but same time it lost > the transport. > > > > > Regards, > Oleg. > -- --Guido van Rossum (python.org/~guido)

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

so a pending patch to add a recvall() method to socket.socket: > http://bugs.python.org/issue1103213 > > Victor > -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Customizing Server.close() and wait_closed()

On Mon, Aug 10, 2015 at 7:23 PM, Aymeric Augustin aymeric.augus...@polytechnique.org wrote: Hello Guido, On 10 août 2015, at 15:32, Guido van Rossum gu...@python.org wrote: Folks, can we stop the testy interaction? Oops — sorry about that. I'm personally confused how a protocol can

Re: [python-tulip] await process.wait() hangs forever on process created with a new_event_loop

with some coroutines, but not with create_subprocess_shell. If passing a custom loop to create_subprocess_shell isn't always supported, I was wondering if it's possible to check and raise an exception in subprocess.Process.wait instead of just hanging forever. Thanks, Chetan -- --Guido van

Re: [python-tulip] Running a coroutine at set intervals

a different method is called.) With coroutines I was able to run them with loop.run_until_complete and then return the response messages to the synchronous code. With tasks though there doesn't seem to be a way. On Wednesday, August 5, 2015 at 11:27:01 AM UTC-6, Guido van Rossum wrote: You

Re: [python-tulip] Running a coroutine at set intervals

in the task though? On Wednesday, August 5, 2015 at 4:02:24 AM UTC-6, Guido van Rossum wrote: To start a coroutine from a callback, you wrap the coroutine in a Task. That's all. E.g. (untested) from asyncio import coroutine, get_event_loop @coroutine def coro(): ... yield from something

Re: [python-tulip] StreamWriter.drain cannot be called concurrently

the assert into a RuntimeError? -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] StreamWriter.drain cannot be called concurrently

, you can't control the buffering in the rest of the network or the receiving host -- so we don't provide a direct interface to it). -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Cleanly shutting down a streams server

! warning on exit. My understanding is that this should avoid any BaseException handling issues since it just stops the event loop and doesn't interfere with any running tasks. Is this correct? On Tue, May 5, 2015 at 2:57 PM, Guido van Rossum gu...@python.org wrote: The problem here is most

Re: [python-tulip] Cleanly shutting down a streams server

. Additionally there doesn't seem to be any way of forcing all connections to close (short of adding this logic to the coroutine). Should Server.wait_closed block if there are remaining connections? Is it possible to force these connections closed? Cheers, David -- --Guido van Rossum (python.org

Re: [python-tulip] tulip wiki migration

The wiki pages are preserved in the wiki branch of the repo. If you want to help putting them back in the github wiki slot I can give you repo access. On Apr 11, 2015 9:58 AM, Ludovic Gasc gml...@gmail.com wrote: Hi, At least to me, the most important wiki page of Tulip project was:

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

PS. Anyone who was a committer on the google code repo please drop me a note with your github username so I can add you. On Fri, Apr 10, 2015 at 4:15 PM, Guido van Rossum gu...@python.org wrote: OK, the repo is now https://github.com/python/tulip ! On Fri, Apr 10, 2015 at 11:54 AM, Ludovic

[python-tulip] Moving Tulip repo to GitHub

Because Google code is shutting down, I'm about to migrate the Tulip repo to GitHub. I'll post here again once the migration is done. -- --Guido van Rossum (python.org/~guido)

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

FWIW, I'm running into issues with the migration. It seems the code gets migrated fine but the issues are migrated incompletely (failing at a different place each time). I'm giving up for now. On Wed, Apr 8, 2015 at 10:32 AM, Guido van Rossum gu...@python.org wrote: Because Google code

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

...@gmail.com wrote: Would you migrate wiki pages also? Or, please, just enable it for github project -- I'll transfer those pages manually. On Wed, Apr 8, 2015 at 2:47 PM, Guido van Rossum gu...@python.org wrote: FWIW, I'm running into issues with the migration. It seems the code gets

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

8, 2015 at 1:32:40 PM UTC-4, Guido van Rossum wrote: Because Google code is shutting down, I'm about to migrate the Tulip repo to GitHub. I'll post here again once the migration is done. -- --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Async iterators

On Tue, Mar 24, 2015 at 4:10 AM, Victor Stinner victor.stin...@gmail.com wrote: 2015-03-24 2:44 GMT+01:00 Guido van Rossum gu...@python.org: For seekable() I couldn't find any dynamic implemetations, The first call to io.FileIO.seekable() calls lseek(0, SEEK_CUR). Oops. :( It's safer

Re: [python-tulip] Async iterators

. I will say one thing, I've learned a lot about Python 3's file IO stack :) You're welcome! -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] asyncio.async versus loop.create_task

://python.pro.br | Twitter: @ramalhoorg -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] asyncio.Queue and queue.Queue inconsistency

the full story. FWIW I'm fine with the proposal from queue import Full as QueueFull, Empty as QueueEmpty. We do a similar thing for the exceptions raised by futures (CancelledError and TimeoutError are imported from concurrent.futures, although without renaming). -- --Guido van Rossum (python.org

Re: [python-tulip] Which is the canonical repo for the tulip/asyncio examples?

| Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Professor em: http://python.pro.br | Twitter: @ramalhoorg -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Which is the canonical repo for the tulip/asyncio examples?

is http://aosabook.org/en/index.html, but it looks like 500 lines or less hasn't made it there yet. On Wed, Mar 18, 2015 at 11:03 AM, Luciano Ramalho luci...@ramalho.org wrote: On Wed, Mar 18, 2015 at 2:39 PM, Guido van Rossum gu...@python.org wrote: I don't know. We're probably going

Re: [python-tulip] asyncio 3.4.3 released

already exited. * Add run_aiotest.py to run the aiotest test suite * Add release.py script to build wheel packages on Windows and run unit tests Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Use asyncio.as_completed()

the desired behavior here. I don't think a different exception should be raised, unless I am missing something? -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Use asyncio.as_completed()

Herbert -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Which other futures my come out of asyncio.as_completed?

On Tue, Mar 3, 2015 at 2:06 PM, Luciano Ramalho luci...@ramalho.org wrote: On Tue, Mar 3, 2015 at 1:49 AM, Guido van Rossum gu...@python.org wrote: It's exceedingly subtle -- that's why the docstring contains an example of how to use it. Note the final two lines: for _ in range

Re: [python-tulip] Adding datagram-like protocol (zigbee) not over socket (serial port), design advice needed

On Tue, Mar 3, 2015 at 2:39 PM, Nicolas Di Pietro pote...@gmail.com wrote: Hi Guido, Thank you for taking some time to answer this. 2015-03-03 6:05 GMT+01:00 Guido van Rossum gu...@python.org: I'll try to give some hints on Nicolas's original question. I agree with Luciano that posting

Re: [python-tulip] Adding datagram-like protocol (zigbee) not over socket (serial port), design advice needed

Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Which other futures my come out of asyncio.as_completed?

argument may be yielded by as_completed? Thanks! -- Luciano Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Weak UDP support in asyncio

). Regards Antoine. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Thread safety

-- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] asyncio.iscoroutinefunction and partials

asyncio.iscoroutinefunction(getattr(func, 'func', None)) What do you think? Best regards Ron Cohen CTO co-founder @ Opbeat -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Call protocol.connection_lost() when the creation of transport failed?

What would Twisted do? (WWTD) On Wed, Jan 28, 2015 at 6:20 PM, Victor Stinner victor.stin...@gmail.com wrote: 2015-01-29 2:47 GMT+01:00 Guido van Rossum gu...@python.org: Doesn't the exception bubble up to the caller of create_connection()? Yes, it does. So what's the problem

Re: [python-tulip] Re: Call protocol.connection_lost() when the creation of transport failed?

change other functions creating pairs of (transport, protocol). These methods currently only call transport.close() on error. Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Bugfixes in the ProactorEventLoop

this. I have pending (and working!) patches for signal handling, I should update them. That sounds good. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Bugfixes in the ProactorEventLoop

when cancelling a _WaitHandleFuture http://bugs.python.org/issue23095 race condition related to IocpProactor.connect_pipe() http://bugs.python.org/issue23293 Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Cross-framework coroutines

, Guido van Rossum gu...@python.org wrote: On Sun, Jan 25, 2015 at 2:52 PM, Ben Darnell b...@bendarnell.com wrote: On Sun, Jan 25, 2015 at 5:31 PM, Guido van Rossum gu...@python.org wrote: I'm probably a bit dense today, but without browsing the code I'm not entirely sure how your thing works

Re: [python-tulip] asyncio_tkinter doesn't work

sense, but I also suspect that that would take away some of the (relative) elegance of using asyncio in the first place. Also, Let me play with these ideas some more. It would be a neat demo if it worked. --Guido On Sat, May 17, 2014 at 4:40 PM, Guido van Rossum gu...@python.org

Re: [python-tulip] Best practice for managing loop: don't close it (really!?)

own code actually created the loop instead of merely fetching it with asyncio.get_event_loop()? Is that a sensible recommendation? Cheers, Luciano -- Luciano Ramalho Twitter: @ramalhoorg Professor em: http://python.pro.br Twitter: @pythonprobr -- --Guido van Rossum (python.org

Re: [python-tulip] Best way to read/write files with AsyncIO

these info: https://code.google.com/p/tulip/wiki/ThirdParty#Filesystem I don't understand the status on Windows when the ProactorEventLoop is used: are filesystem operation blocking or not? Latest discussion on the Linux kernel: http://lwn.net/Articles/612483/ Victor -- --Guido van Rossum

Re: [python-tulip] Can you send to a broadcast address with datagram_endpoint?

the create_connection does. I did search the internet for quite a while and didn't see any examples or anyone really talking about udp broadcast. Sorry if I just don't understand python enough and it's just some trivial method passing thing. thanks -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] asyncio.wait_for and Condition

: return False Any thoughts? -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Idiomatic way to wait on two different tasks?

appropriate to my situation? To recap, I want to wait on the first completed task of two (or more) heterogenous task types. And then I want to process results from each task type in a distinct way. I'd gladly welcome any advice on the topic. -- Don -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Python 3.4.2 released, release of asyncio 3.4.2?

I still haven't gotten to this. But at least I've tagged 3.4.2 in the tulip repo (as the rev that matched the asyncio package in the CPython 3.4.2 tree exactly). On Thu, Oct 9, 2014 at 6:04 PM, Guido van Rossum gu...@python.org wrote: Yeah, we should release a Tulip 3.4.2 release that's

Re: [python-tulip] Wait until a stream is closed?

I should not wait until a socket is closed? Is it safe to call writer.close() and exit immediatly? The scheduled callback which will close the socket may not be called immediatly. Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Re: Wait until a stream is closed?

) loop.close() NOTE: If an error happens to the transport the loop.close() call won't actually be reached; you can solve this in various ways, e.g. by not calling set_exception(), or using try/finally. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] UDP server, error_receveid and connection_lost

). The connection_lost() callback is only called when the transport is closed using transport.close(). For error_received, the documentation is here: https://docs.python.org/dev/library/asyncio-protocol.html#asyncio.DatagramProtocol.error_received Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Wait until a stream is closed?

On Sun, Oct 12, 2014 at 3:37 PM, Victor Stinner victor.stin...@gmail.com wrote: 2014-10-12 21:55 GMT+02:00 Guido van Rossum gu...@python.org: So you're only concerned about the streams example, right? Oh no sorry, my question was general. It's just that I discovered the issue when working

Re: [python-tulip] Python 3.4.2 released, release of asyncio 3.4.2?

wrote: Hi, Python 3.4.2 has been released. What's the status of Tulip? Can we release a version 3.4.2 too? FYI Trollius 1.0.2 should be synchronized with Python 3.4.2. Victor -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] global name \'s\' is not defined') ('done:', 1, '; ok:', 0)

. Marco -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] xml-rpc Server with asyncio

Server library for asyncio? 2) If I need to build my own xml-rpc server library for asyncio, what's the best starting point? -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] Support for select exception filedescriptor set or POLLPRI/POLLERR?

Guido van Rossum gu...@python.org: It's totally fine to submit patches for this. I have never seen a use case for this in my life, but I am glad that you have one! On Thu, Sep 25, 2014 at 8:05 AM, David Jander djan...@gmail.com wrote: Hi all, I have been using asyncore until now, and am

Re: [python-tulip] ProactorEventLoop and add_reader/add_writer

it with ProactorEventLoop. Thanks, Arve -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] closing event loops

activities you have going and come up with a way to shut those down in an orderly fashion, rather than just shooting all tasks. -- --Guido van Rossum (python.org/~guido)

Re: [python-tulip] closing event loops

that would actually be helped by the same helper to warrant adding the new API you are proposing. API design generally ought to follow from use cases encountered frequently, otherwise you get a complex hodge-podge that is hard to learn. -- --Guido van Rossum (python.org/~guido)

  1   2   3   >