HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
python-trio
trio
Python2018–2026
python-trio / trio

trio

Trio – a friendly Python library for async concurrency and I/O

Systems & InfrastructureNetworkingLibraries & SDKs
Explore on GitHubRead Hacker News discussions
15Distinct people
17Mentions
0Explicit recommenders
7.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Trio – a friendly Python library for async concurrency and I/O

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2018-04-24 07:00:07 UTC to 2026-04-03 19:31:13 UTC.

012342018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC404
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC211
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

17 sources
ciconia·May 13, 2023
> I am interested in how concurrency can be represented elegantly and efficiently This was the main driving force behind the development of Polyphony. I've been exploring all the different ways of expressing concurrent operations: callbacks, promises, async/await. Each of these solutions has its drawbacks: callbacks make you split your app logic across different functions; promises are a somewhat better API but do not solve the split logic problem; async/await potentially leads to two types of functions (the "what color is your function" problem). All three kind of break Ruby's exception handling model. In contrast, Polyphony relies on Ruby fibers, which provide a base for implementing cooperative concurrency, where each fiber does its work, yielding execution whenever it performs a blocking operation, such as reading from a socket, or wa
Read the rest
iting for a timeout. In addition, fibers are arranged into a tree where each fiber is considered the child of the fiber from which it was spawned, and is guaranteed to stop executing before its immediate parent stops executing. Any uncaught exception raised by a fiber will be propagated up the fiber tree. This implements a pattern known as Structured Concurrency [1]. Fibers can communicate by sending each other messages, in a similar fashion to Erlang/Elixir processes. There's no direct equivalent in Polyphony to the program you included, which seems to implement two generators running asynchronously. But the following does something similar. def number_generator n = 0 loop do client = receive client << (n += 1) end end task1 = spin { number_generator } task2 = spin { number_generator } 10.times do task1 << Fiber.current puts "next number from task1: #{receive}" task2 << Fiber.current puts "next number from task2: #{receive}" end So in the above program, two fibers are spun, each running the same number generator, which repeatedly waits for a message which is actually the fiber of the "client", and sends the next number to the client. In Python there's the Trio library [2], which implements structured concurrency, and which was actually one of the main inspirations for developing Polyphony. [1] https://en.wikipedia.org/wiki/Structured_concurrency [2] https://github.com/python-trio/trio
In Polyphony: Fine-Grained Concurrency for Ruby
nbadg·Feb 11, 2023
I'll +1 the Trio shoutout [1], but it's worth emphasizing that the core concept of Trio (nurseries) now exists in the stdlib in the form of task groups [2]. The article mentions this very briefly, but it's easy to miss, and I wouldn't describe it as a solution to this bug, anyways. Rather, it's more of a different way of writing multitasking code, which happens to make this class of bug impossible. [1] https://github.com/python-trio/trio [2] https://docs.python.org/3/library/asyncio-task.html#task-gro...
In A Heisenbug lurking in async Python
samsquire·Jan 13, 2023
It's similar to manual memory management: you have to remember to do the other side of the thing you're doing. Structured concurrency is one approach to solving this problem. In a structured concurrency a promise would not go out of scope unhandled. Not sure how you would add APIs for it though in Javascript. See Python's trio nurseries idea which uses a python context manager. https://github.com/python-trio/trio I'm working on a syntax for state machines and it could be used as a DSL for promises. It looks similar to a bash pipeline but it matches predicates similar to prolog. In theory you could wire up a tree (graph if you have joins) of structured concurrency with this DSL. https://github.com/samsquire/ideas4#558-assign-location-mult...
In The gotcha of unhandled promise rejections
quietbritishjim·Nov 10, 2022
Not complete - doesn't include Task Groups [1] In fairness they were only included in asyncio as of Python 3.11, which was released a couple of weeks ago. These were an idea originally from Trio [2] where they're called "nurseries" instead of "task groups". My view is that you're better off using Trio, or at least anyio [3] which gives a Trio-like interface to asyncio. One particularly nice thing about Trio (and anyio) is that there's no way to spawn background tasks except to use task groups i.e. there's no analogue of asyncio's create_task() function. That is good because it guarantees that no task is ever left accidentally running in the background and no exception left silently uncaught. [1] https://docs.python.org/3/library/asyncio-task.html#task-gro... [2] https://github.com/python-trio/trio [3] https://anyio.readthedocs.io/en/lates
Read the rest
t/
In Python Asyncio
quietbritishjim·May 25, 2022
> I do not recall that the author of this pamphlet has ever done much He made the Trio library, which is ridiculously good and also ridiculously hard to implement (just look at this issue [1] for example where he carefully examines the three (!) different async APIs on Windows). Lessons from it are being folded back into the asyncio library in core Python (e.g. exception groups) so everyone benefits even if they don't use Trio directly. [1] https://github.com/python-trio/trio/issues/52
In The domain for the Python Requests library is expired
hermod·Nov 14, 2019
With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I'm optimistic about its future. There were plans to use it for requests v3 until the fundraiser fiasco [5]. [0] https://github.com/python-trio/trio [1] https://vorpus.org/blog/announcing-trio/ [2] https://trio.readthedocs.io/en/stable/reference-core.html#us... [3] https://trio.readthedocs.io/en/latest/reference-core.html#ca... [4] https://vorpus.org/blog/notes-on-structured-concurrency-or-g... [5] https://vorpus.org/blog/why-i
Read the rest
m-not-collaborating-with-kennet...
In Why Is the Migration to Python 3 Taking So Long?
j88439h84·May 25, 2019
I just watched your talk, and found it very interesting, thanks for sharing it! I hope you can do the data flow analysis. That would be so cool and SO useful. Python certainly has the ability to collect the data. A couple existing tools make use of this. For example, MonkeyType and Birdseye observe the values that are passed around by tracing execution during test runs (or even during a production run, but the performance impact can be substantial). https://github.com/Instagram/MonkeyType https://github.com/alexmojaki/birdseye Even more information can be gleaned from the gc module (see https://mg.pov.lt/objgraph/ for a tool using it). These tools make good progress, but I'd be very interested to see what a software-visualization expert would come up with. I'd also love to see how a concurrent execution tree can be visualized. For example
Read the rest
, the wonderful Trio concurrency library is built on a tree of concurrent tasks. It would be so cool to see which events are happening at the same time. I've never seen a visualization of how it'd work. (The Trio team is also extremely friendly on their Gitter chat.) https://github.com/python-trio/trio Structured logging is yet another exciting area. Can we generate visualizations from logs in OpenTracing/OpenCensus format? Some existing work is https://github.com/jonathanj/eliottree Gary Bernhardt's "A whole new world" talk https://www.destroyallsoftware.com/talks/a-whole-new-world proposes extracting data from logs and highlighting important lines from tracebacks and and slow lines from trace timings in the editor. I haven't used Structurizr, but it seems interesting. Do you have thoughts on it? https://structurizr.com/ has a python port at https://github.com/sixty-north/structurizr-python
In Show HN: Sourcetrail – Visual Source Explorer Now Supports Python

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.