Releases: python-trio/trio
v0.25.0
Full Changelog: v0.24.0...v0.25.0
Breaking changes
-
The
strict_exception_groupsparameter now defaults toTrueintrio.runandtrio.lowlevel.start_guest_run.trio.open_nurserystill defaults to the same value as was specified intrio.run/trio.lowlevel.start_guest_run, but if you didn't specify it there then all subsequent calls totrio.open_nurserywill change.
This is unfortunately very tricky to change with a deprecation period, as raising aDeprecationWarningwheneverstrict_exception_groupsis not specified would raise a lot of unnecessary warnings.Notable side effects of changing code to run with
strict_exception_groups==True-
If an iterator raises
StopAsyncIterationorStopIterationinside a nursery, then python will not recognize wrapped instances of those for stopping iteration. -
trio.run_processis now documented that it can raise anExceptionGroup. It previously could do this in very rare circumstances, but withstrict_exception_groupsset toTrueit will now do so whenever exceptions occur indeliver_cancelor with problems communicating with the subprocess.- Errors in opening the process is now done outside the internal nursery, so if code previously ran with
strict_exception_groups=Truethere are cases now where anExceptionGroupis no longer added.
- Errors in opening the process is now done outside the internal nursery, so if code previously ran with
-
trio.TrioInternalError.__cause__might be wrapped in one or moreExceptionGroups <ExceptionGroup>(#2786)
-
Features
-
Add
trio.testing.wait_all_threads_completed, which blocks until no threads are running tasks. This is intended to be used in the same way astrio.testing.wait_all_tasks_blocked. (#2937) -
Pathis now a subclass ofpathlib.PurePath, allowing it to interoperate with other standard
pathlibtypes.Instantiating
Pathnow returns a concrete platform-specific subclass, one ofPosixPathor
WindowsPath, matching the behavior ofpathlib.Path. (#2959)
Bugfixes
- The pthread functions are now correctly found on systems using vanilla versions of musl libc. (#2939)
Miscellaneous internal changes
- use the regular readme for the PyPI long_description (#2866)
v0.24.0
Full Changelog: v0.23.2...v0.24.0
Features
-
New helper classes:
testing.RaisesGroupandtesting.Matcher.In preparation for changing the default of
strict_exception_groupstoTrue, we're introducing a set of helper classes that can be used in place ofpytest.raisesin tests, to check for an expectedExceptionGroup.
These are provisional, and only planned to be supplied until there's a good solution inpytest. See pytest-dev/pytest#11538 (#2785)
Deprecations and removals
MultiErrorhas been fully removed, and all relevant trio functions now raise ExceptionGroups instead. This should not affect end users that have transitioned to usingexcept*or catching ExceptionGroup/BaseExceptionGroup. (#2891)
v0.23.2
Full Changelog: v0.23.1...v0.23.2
Features
- TypeVarTuple is now used to fully type
nursery.start_soon(),trio.run(),trio.to_thread.run_sync(), and other similar functions accepting(func, *args). This means type checkers will be able to verify types are used correctly.nursery.start()is not fully typed yet however. (#2881)
Bugfixes
- Make pyright recognize
open_memory_channelas generic. (#2873)
Miscellaneous internal changes
v0.23.1
v0.23.0
Full Changelog: v0.22.2...v0.23.0
Headline features
- Add type hints. (#543)
Features
- When exiting a nursery block, the parent task always waits for child tasks to exit. This wait cannot be cancelled. However, previously, if you tried to cancel it, it would inject a
Cancelledexception, even though it wasn't cancelled. Most users probably never noticed either way, but injecting aCancelledhere is not really useful, and in some rare cases caused confusion or problems, so Trio no longer does that. (#1457) - If called from a thread spawned by
trio.to_thread.run_sync,trio.from_thread.runandtrio.from_thread.run_syncnow reuse the task and cancellation status of the host task; this means that context variables and cancel scopes naturally propagate 'through' threads spawned by Trio. You can also usetrio.from_thread.check_cancelledto efficiently check for cancellation without reentering the Trio thread. (#2392) trio.lowlevel.start_guest_runnow does a bit more setup of the guest run before it returns to its caller, so that the caller can immediately make calls totrio.current_time,trio.lowlevel.spawn_system_task,trio.lowlevel.current_trio_token, etc. (#2696)
Bugfixes
- When a starting function raises before calling
trio.TaskStatus.started,trio.Nursery.startwill no longer wrap the exception in an undocumentedExceptionGroup. Previously,trio.Nursery.startwould incorrectly raise anExceptionGroupcontaining it when usingtrio.run(..., strict_exception_groups=True). (#2611)
Deprecations and removals
- To better reflect the underlying thread handling semantics, the keyword argument for
trio.to_thread.run_syncthat was previously calledcancellableis now namedabandon_on_cancel. It still does the same thing -- allow the thread to be abandoned if the call totrio.to_thread.run_syncis cancelled -- but since we now have other ways to propagate a cancellation without abandoning the thread, "cancellable" has become somewhat of a misnomer. The oldcancellablename is now deprecated. (#2841) - Deprecated support for
math.inffor thebacklogargument inopen_tcp_listeners, making its docstring correct in the fact that onlyTypeErroris raised if invalid arguments are passed. (#2842)
Removals without deprecations
- Drop support for Python3.7 and PyPy3.7/3.8. (#2668)
- Removed special
MultiErrortraceback handling for IPython. As of version 8.15ExceptionGroupis handled natively. (#2702)
Miscellaneous internal changes
- Trio now indicates its presence to
sniffiousing thesniffio.thread_localinterface that is preferred since sniffio v1.3.0. This should be less likely than the previous approach to causesniffio.current_async_libraryto return incorrect results due to unintended inheritance of contextvars. (#2700) - On windows, if SIO_BASE_HANDLE failed and SIO_BSP_HANDLE_POLL didn't return a different socket, runtime error will now raise from the OSError that indicated the issue so that in the event it does happen it might help with debugging. (#2807)