mirrors/guru
1
0
Fork 0
mirror of https://github.com/gentoo-mirror/guru.git synced 2026-07-18 03:23:20 -04:00
Code Issues Packages Projects Releases Wiki Activity

dev-python/trio-asyncio: new package

Browse Source 
Package-Manager: Portage-2.3.96, Repoman-2.3.22
Signed-off-by: Alessandro Barbieri <lssndrbarbieri@gmail.com>
This commit is contained in:
Alessandro Barbieri
2020-03-29 11:23:26 +02:00
parent 8a000ba421
commit 7395f995d7
3 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
dev-python/trio-asyncio/metadata.xml Normal file
View File

@@ -0,0 +1,27 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<maintainer type="person">
<email>lssndrbarbieri@gmail.com</email>
<name>Alessandro Barbieri</name>
</maintainer>
<longdescription>
Rationale
Trio has native concepts of tasks and task cancellation. Asyncio is based on callbacks and chaining Futures, albeit with nicer syntax, which make handling of failures and timeouts fundamentally less reliable, especially in larger programs. Thus, you really want to base your async project on Trio.
On the other hand, there are quite a few asyncio-enhanced libraries. You really don't want to re-invent any wheels in your project.
Thus, being able to use asyncio libraries from Trio is useful. trio-asyncio enables you to do that, and more.
Transparent vs. explicit translation
trio_asyncio does not try to magically allow calling await trio_code() from asyncio or vice versa. There are multiple reasons for this; the executive summary is that cross-domain calls can't be made to work correctly, and any such call is likely to result in an irrecoverable error. You need to keep your code's asyncio and trio domains rigidly separate.
Fortunately, this is not difficult.
</longdescription>
<upstream>
<remote-id type="github">python-trio/trio-asyncio</remote-id>
<remote-id type="pypi">trio-asyncio</remote-id>
</upstream>
</pkgmetadata>