* :func:inspect.iscoroutinefunction and the like now give correct answers when
called on KI-protected functions.
* Rework KeyboardInterrupt protection to track code objects, rather than frames,
as protected or not. The new implementation no longer needs to access
frame.f_locals dictionaries, so it won't artificially extend the lifetime of
local variables. Since KeyboardInterrupt protection is now imposed statically
(when a protected function is defined) rather than each time the function runs,
its previously-noticeable performance overhead should now be near zero.
The lack of a call-time wrapper has some other benefits as well:
* :func:inspect.iscoroutinefunction and the like now give correct answers when
called on KI-protected functions.
* Calling a synchronous KI-protected function no longer pushes an additional stack
frame, so tracebacks are clearer.
* A synchronous KI-protected function invoked from C code (such as a weakref
finalizer) is now guaranteed to start executing; previously there would be a brief
window in which KeyboardInterrupt could be raised before the protection was
established.
* One minor drawback of the new approach is that multiple instances of the same
closure share a single KeyboardInterrupt protection state (because they share a
single code object). That means that if you apply
trio.lowlevel.enable_ki_protection to some of them
and not others, you won't get the protection semantics you asked for. See the
documentation of trio.lowlevel.enable_ki_protection
for more details and a workaround.
* Rework foreign async generator finalization to track async generator
ids rather than mutating ag_frame.f_locals. This fixes an issue
with the previous implementation: locals' lifetimes will no longer be
extended by materialization in the ag_frame.f_locals dictionary that
the previous finalization dispatcher logic needed to access to do its work.
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-trio?expand=0&rev=52
* :func:`trio.move_on_after` and :func:`trio.fail_after`
previously set the deadline relative to initialization time,
instead of more intuitively upon entering the context
manager. This might change timeouts if a program relied on
this behavior. If you want to restore previous behavior you
should instead use trio.move_on_at(trio.current_time() +
...). flake8-async has a new rule to catch this, in case
you're supporting older trio versions. See :ref:`ASYNC122`.
* :meth:`CancelScope.relative_deadline` and
:meth:`CancelScope.is_relative` added, as well as a
relative_deadline parameter to __init__. This allows
initializing scopes ahead of time, but where the specified
relative deadline doesn't count down until the scope is
entered.
* :class:`trio.Lock` and :class:`trio.StrictFIFOLock` will now
raise :exc:`trio.BrokenResourceError` when
:meth:`trio.Lock.acquire` would previously stall due to the
owner of the lock exiting without releasing the lock.
* trio.move_on_at, trio.move_on_after, trio.fail_at and
trio.fail_after now accept shield as a keyword argument. If
specified, it provides an initial value for the
~trio.CancelScope.shield attribute of the trio.CancelScope
object created by the context manager.
* Added :func:`trio.lowlevel.add_parking_lot_breaker` and
:func:`trio.lowlevel.remove_parking_lot_breaker` to allow
creating custom lock/semaphore implementations that will
break their underlying parking lot if a task exits
unexpectedly. :meth:`trio.lowlevel.ParkingLot.break_lot` is
also added, to allow breaking a parking lot intentionally.
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-trio?expand=0&rev=51
