Re: [Async-sig] Asynchronous cleanup is a problem

On Wed, Jul 6, 2016 at 6:42 AM, Cory Benfield wrote: > >> On 6 Jul 2016, at 13:09, David Beazley wrote: >> >> Curio uses asynchronous context managers for much more than closing sockets >> (which frankly is the least interesting thing). For example, they're

Re: [Async-sig] [ANN] async_generator v1.2 released

On Fri, Nov 25, 2016 at 10:46 AM, Alex Grönholm <alex.gronh...@nextday.fi> wrote: > 25.11.2016, 12:09, Nathaniel Smith kirjoitti: >> >> On Thu, Nov 24, 2016 at 11:59 PM, Alex Grönholm >> <alex.gronh...@nextday.fi> wrote: >>> >>> 25.11.2016, 09:2

Re: [Async-sig] [ANN] async_generator v1.2 released

On Fri, Nov 25, 2016 at 12:03 AM, Alex Grönholm <alex.gronh...@nextday.fi> wrote: > 24.11.2016, 23:23, Nathaniel Smith kirjoitti: > > On Nov 23, 2016 11:29 PM, "Alex Grönholm" <alex.gronh...@nextday.fi> wrote: >> >> 23.11.2016, 01:34, Nathaniel Smith kirj

Re: [Async-sig] Adding asyncio.run() function in Python 3.6

What's the use case for the async generator version? Could the yield be replaced by 'await loop.shutting_down()'? On Nov 16, 2016 10:12 AM, "Yury Selivanov" wrote: > One of the remaining problems with the event loop in asyncio is > bootstrapping/finalizing asyncio

Re: [Async-sig] Feedback, loop.load() function

It looks like your "load average" is computing something very different than the traditional Unix "load average". If I'm reading right, yours is a measure of what percentage of the time the loop spent sleeping waiting for I/O, taken over the last 60 ticks of a 1 second timer (so generally slightly

Re: [Async-sig] async documentation methods

On Mon, Jul 3, 2017 at 11:49 PM, Alex Grönholm wrote: > The real question is: why doesn't vanilla Sphinx have any kind of support > for async functions which have been part of the language for quite a while? Because no-one's sent them a PR, I assume. They're pretty

Re: [Async-sig] question re: asyncio.Condition lock acquisition order

On Tue, Jun 27, 2017 at 4:15 AM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > On Tue, Jun 27, 2017 at 3:29 AM, Nathaniel Smith <n...@pobox.com> wrote: >> In fact asyncio.Lock's implementation is careful to maintain strict >> FIFO fairness, i.e. whoever calls ac

Re: [Async-sig] "read-write" synchronization

On Mon, Jun 26, 2017 at 6:41 PM, Chris Jerdonek wrote: > On Mon, Jun 26, 2017 at 12:37 PM, Dima Tisnek wrote: >> Chris, here's a simple RWLock implementation and analysis: >> ... >> Obv., this code could be nicer: >> * separate context managers for

Re: [Async-sig] [ann] sphinxcontrib-trio: make sphinx better at documenting functions/methods, esp. for async/await code

[dropped python-announce from CC list] On Fri, May 12, 2017 at 9:17 AM, Brett Cannon wrote: > So are you going to try to upstream this? ;) Realistically, for me this is a side-project to a side-project, so it may require someone else do the integration work, but:

Re: [Async-sig] async/sync library reusage

On Thu, Jun 8, 2017 at 3:32 PM, manuel miranda wrote: > Hello everyone, > > After using asyncio for a while, I'm struggling to find information about > how to support both synchronous and asynchronous use cases for the same > library. > > I.e. imagine you have a package

Re: [Async-sig] Cancelling SSL connection

SSLObject.unwrap has the contract that if it finishes successfully, then the SSL connection has been cleanly shut down and both sides remain in sync, and can continue to use the socket in unencrypted mode. When asyncio calls unwrap before the handshake has completed, then this contract is

Re: [Async-sig] "read-write" synchronization

On Mon, Jun 26, 2017 at 12:37 PM, Dima Tisnek wrote: > Note that `.unlock` cannot validate that it's called by same coroutine > as `.lock` was. > That's because there's no concept for "current_thread" for coroutines > -- there can be many waiting on each other in the stack.

Re: [Async-sig] async generator confusion or bug?

I actually thought that async generators already guarded against this using their ag_running attribute. If I try running Dima's example with async_generator, I get: sending user-1 received user-1 sending user-2 sending user-0 Traceback (most recent call last): [...] ValueError: async generator

Re: [Async-sig] "read-write" synchronization

On Sun, Jun 25, 2017 at 2:13 PM, Chris Jerdonek wrote: > I'm relatively new to async programming in Python and am thinking > through possibilities for doing "read-write" synchronization. > > I'm using asyncio, and the synchronization primitives that asyncio > exposes are

Re: [Async-sig] awaiting task is not chaining exception

On Sun, Nov 12, 2017 at 7:27 AM, Guido van Rossum wrote: > On Sun, Nov 12, 2017 at 2:53 AM, Chris Jerdonek > wrote: >> >> By the way, since we're already on the subject of asyncio tasks and >> (truncated) stack traces, this looks like a good

Re: [Async-sig] Simplifying stack traces for tasks?

On Tue, Nov 14, 2017 at 6:54 AM, Mark E. Haase wrote: > If an exception is thrown while the `asyncio` event loop is running, the > stack trace is pretty complicated. Here's an example: > [...] > > I'm posting here to get constructive criticism on the concept and would also >

Re: [Async-sig] awaiting task is not chaining exception

On Fri, Nov 10, 2017 at 9:52 PM, Chris Jerdonek wrote: > Hi, I recently encountered a situation with asyncio where the stack > trace is getting truncated: an exception isn't getting chained as > expected. > > I was able to reduce it down to the code below. > > The

[Async-sig] ANN: Trio v0.2.0 released

Hi all, I'm proud to announce the release of Trio v0.2.0. Trio is a new async concurrency library for Python that's obsessed with usability and correctness -- we want to make it easy to get things right. This is the second public release, and it contains major new features and bugfixes from 14

Re: [Async-sig] New blog post: Notes on structured concurrency, or: Go statement considered harmful

On Thu, Apr 26, 2018 at 7:55 PM, Dima Tisnek wrote: > My 2c after careful reading: > > restarting tasks automatically (custom nursery example) is quite questionable: > * it's unexpected > * it's not generally safe (argument reuse, side effects) > * user's coroutine can be

Re: [Async-sig] New blog post: Notes on structured concurrency, or: Go statement considered harmful

On Wed, Apr 25, 2018 at 9:43 PM, Guido van Rossum wrote: > Now there's a PEP I'd like to see. Which part? -n -- Nathaniel J. Smith -- https://vorpus.org ___ Async-sig mailing list Async-sig@python.org

Re: [Async-sig] New blog post: Notes on structured concurrency, or: Go statement considered harmful

On Wed, Apr 25, 2018 at 3:17 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 25 Apr 2018 02:24:15 -0700 > Nathaniel Smith <n...@pobox.com> wrote: >> Hi all, >> >> I just posted another essay on concurrent API design: >> >> https://vorpu

Re: [Async-sig] task.result() and exception traceback display

I haven't thought about this enough to have an opinion about whether this is correct or how it could be improved, but I can explain why you're seeing what you're seeing :-). The traceback is really a trace of where the exception went after it was raised, with new lines added to the top as it

[Async-sig] Blog post: Timeouts and cancellation for humans

Hi all, Folks here might be interested in this new blog post: https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ It's a detailed discussion of pitfalls and design-tradeoffs in APIs for timeout and cancellation, and has a proposal for handling them in a more Pythonic way. Any feedback

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

On Sun, Jan 14, 2018 at 6:33 PM, Dima Tisnek wrote: > Perhaps the latter is what `shield` should do? That is detach computation as > opposed to blocking the caller past caller's deadline? Well, it can't do that in trio :-). One of trio's core design principles is: no detached

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

On Sun, Jan 14, 2018 at 5:11 AM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > On Sun, Jan 14, 2018 at 3:33 AM, Nathaniel Smith <n...@pobox.com> wrote: >> On Fri, Jan 12, 2018 at 4:17 AM, Chris Jerdonek >> <chris.jerdo...@gmail.com> wrote: >>> Say

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

On Sun, Jan 14, 2018 at 2:45 PM, Nick Badger wrote: >> However, I think this is probably a code smell. Like all code smells, >> there are probably cases where it's the right thing to do, but when >> you see it you should stop and think carefully. > > Huh. That's a really good

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

On Fri, Jan 12, 2018 at 4:17 AM, Chris Jerdonek wrote: > Thanks, Nathaniel. Very instructive, thought-provoking write-up! > > One thing occurred to me around the time of reading this passage: > >> "Once the cancel token is triggered, then all future operations on that

Re: [Async-sig] Blog post: Timeouts and cancellation for humans

On Thu, Jan 11, 2018 at 7:49 PM, Dima Tisnek wrote: > Very nice read, Nathaniel. > > The post left me wondering how cancel tokens interact or should > logically interact with async composition, for example: > > with move_on_after(10): > await someio.gather(a(), b(), c()) > >

Re: [Async-sig] avoiding accidentally calling blocking code

On Wed, Feb 14, 2018 at 12:42 AM, Chris Jerdonek wrote: > Thanks, Dima and Andrew, for your suggestions. > > Re: loop.slow_callback_duration, that's interesting. I didn't know > about that. However, it doesn't seem like that alone would work to > catch many operations

[Async-sig] new library: sniffio – Sniff out which async library your code is running under

Hi all, A number of people are working on packages that support multiple async backends (e.g., asyncio + trio, or trio + curio, or trio + twisted, ...). So then the question arises... how can I figure out which async library my user is actually using? Answer: install sniffio, and then call

Re: [Async-sig] new library: sniffio – Sniff out which async library your code is running under

On Sat, Aug 18, 2018 at 2:44 PM, Chris Jerdonek wrote: > The kind of alternative I had in mind for a neutral location is > setting an attribute with an agreed upon name on a module in the > standard lib, perhaps something like > `contextvars.current_async_library_cvar` to use your naming. This is

Re: [Async-sig] new library: sniffio – Sniff out which async library your code is running under

On Fri, Aug 17, 2018, 09:09 Alex Grönholm wrote: > This was my approach: > > def _detect_running_asynclib() -> str: > if 'trio' in sys.modules: > from trio.hazmat import current_trio_token > try: > current_trio_token() > except RuntimeError: >

Re: [Async-sig] new library: sniffio – Sniff out which async library your code is running under

On Fri, Aug 17, 2018 at 11:44 PM, Chris Jerdonek wrote: > On Fri, Aug 17, 2018 at 12:50 PM, Nathaniel Smith wrote: >> On Fri, Aug 17, 2018, 12:12 Chris Jerdonek wrote: >>> >>> Did you also think about whether it would be possible for a library to >>> adver

[Async-sig] New blog post: Notes on structured concurrency, or: Go statement considered harmful

Hi all, I just posted another essay on concurrent API design: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ This is the one that finally gets at the core reasons why Trio exists; I've been trying to figure out how to write it for at least a year

Re: [Async-sig] asyncio.Lock equivalent for multiple processes

Pretty sure you want to add a try/finally around that yield, so you release the lock on errors. On Tue, Apr 17, 2018, 14:39 Ludovic Gasc wrote: > 2018-04-17 15:16 GMT+02:00 Antoine Pitrou : > >> >> >> You could simply use something like the first 64 bits

Re: [Async-sig] await question

Yeah, 'await' makes it *possible* for the function you're calling to return control to the event loop, but returning is still an explicit action that the function has to take. In asyncio, the only operation that actually returns control to the event loop is awaiting a Future object. In Trio, we

[Async-sig] Preventing `yield` inside certain context managers

This proposal might be of interest to folks here: https://discuss.python.org/t/preventing-yield-inside-certain-context-managers/1091 I posted the main text there instead of here because it's a change to the core interpreter, but the motivation is async APIs. Probably best to post replies there,

Re: [Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

On Wed, Mar 27, 2019 at 1:49 PM Guido van Rossum wrote: > > On Wed, Mar 27, 2019 at 1:23 PM Nathaniel Smith wrote: >> >> On Wed, Mar 27, 2019 at 10:44 AM Daniel Nugent wrote: >> > >> > FWIW, the ayncio_run_encapsulated approach does not work with the

Re: [Async-sig] Reliably make unhandled exceptions crash the event loop

On Mon, Feb 25, 2019 at 4:15 PM Josh Quigley <0zer...@gmail.com> wrote: > > I've realised the error of my ways: because Task separates the scheduling > from the response handling, you cannot know if an exception is unhandled > until the task is deleted. So in my example the reference means the