Run towncrier, copyedit README/docs, and bump version to 0.14.0 for release

Author: oremanj

README.rst

@@ -1,18 +1,18 @@
+.. image:: https://img.shields.io/pypi/v/trio-asyncio.svg
+   :target: https://pypi.org/project/trio-asyncio
+   :alt: Latest PyPI version
+
 .. image:: https://img.shields.io/badge/chat-join%20now-blue.svg
    :target: https://gitter.im/python-trio/general
    :alt: Join chatroom
 
 .. image:: https://img.shields.io/badge/docs-read%20now-blue.svg
    :target: https://trio-asyncio.readthedocs.io/en/latest/?badge=latest
-   :alt: Documentation Status
-
-.. image:: https://travis-ci.org/python-trio/trio-asyncio.svg?branch=master
-   :target: https://travis-ci.org/python-trio/trio-asyncio
-   :alt: Automated test status (Linux and MacOS)
+   :alt: Documentation status
 
-.. image:: https://ci.appveyor.com/api/projects/status/github/python-trio/trio-asyncio?svg=true;branch=master
-   :target: https://ci.appveyor.com/project/python-trio/trio-asyncio/history
-   :alt: Automated test status (Windows)
+.. image:: https://github.com/python-trio/trio-asyncio/actions/workflows/ci.yml/badge.svg
+   :target: https://github.com/python-trio/trio-asyncio/actions/workflows/ci.yml
+   :alt: Automated test status
 
 .. image:: https://codecov.io/gh/python-trio/trio-asyncio/branch/master/graph/badge.svg
    :target: https://codecov.io/gh/python-trio/trio-asyncio
@@ -26,8 +26,8 @@
 **trio-asyncio** is a re-implementation of the ``asyncio`` mainloop on top of
 Trio.
 
-Trio-Asyncio requires at least Python 3.7. It is tested on recent versions of
-3.7 through 3.11, plus 3.12-dev.
+trio-asyncio requires at least Python 3.8. It is tested on recent versions of
+3.8 through 3.12.
 
 +++++++++++
  Rationale

docs/source/history.rst

@@ -5,6 +5,49 @@ Release history
 
 .. towncrier release notes start
 
+trio-asyncio 0.14.0 (2024-02-07)
+--------------------------------
+
+Features
+~~~~~~~~
+
+- trio-asyncio now implements its :ref:`synchronous event loop <asyncio-loop>`
+  (which is used when the top-level of your program is an asyncio call such as
+  :func:`asyncio.run`, rather than a Trio call such as :func:`trio.run`)
+  using the ``greenlet`` library rather than a separate thread. This provides
+  some better theoretical grounding and fixes various edge cases around signal
+  handling and other integrations; in particular, recent versions of IPython
+  will no longer crash when importing trio-asyncio. Synchronous event loops have
+  been un-deprecated with this change, though we still recommend using an
+  async loop (``async with trio_asyncio.open_loop():`` from inside a Trio run)
+  where possible. (`#137 <https://github.com/python-trio/trio-asyncio/issues/137>`__)
+- trio-asyncio now better respects cancellation semantics for
+  asyncio-to-Trio transitions. The asyncio caller now will not propagate
+  cancellation until the Trio callee actually terminates, and only if
+  the Trio callee terminates by cancellation (rather than, for example,
+  finishing normally because the cancel arrived too late). Additionally,
+  we no longer immediately cancel all Trio tasks started from asyncio
+  context if the entire :func:`open_loop` is cancelled; they only become
+  cancelled when their asyncio caller is cancelled, or when the body of
+  the :func:`open_loop` terminates. (`#140 <https://github.com/python-trio/trio-asyncio/issues/140>`__)
+
+
+Bugfixes
+~~~~~~~~
+
+- trio-asyncio no longer applies a limit to the maximum number of
+  asyncio callbacks (including new task creations) that can be enqueued
+  near-simultaneously. Previously the default limit was 10,000. A limit
+  may still be requested using the *queue_len* parameter to
+  :func:`open_loop`, but this is discouraged because there is no way
+  to fail gracefully upon exceeding the limit; it will most likely just
+  crash your program. (`#130 <https://github.com/python-trio/trio-asyncio/issues/130>`__)
+- Fix an issue where a call to ``TrioEventLoop.call_exception_handler()`` after
+  the loop was closed would attempt to call a method on ``None``. This pattern
+  can be encountered if an ``aiohttp`` session is garbage-collected without being
+  properly closed, for example. (`#134 <https://github.com/python-trio/trio-asyncio/issues/134>`__)
+
+
 trio-asyncio 0.13.0 (2023-12-01)
 --------------------------------
 

docs/source/usage.rst

@@ -130,7 +130,7 @@ In such cases, you can instead keep the old approach (``get_event_loop()`` +
 (and not changed the asyncio event loop policy) you'll still be able to use
 :func:`~trio_asyncio.trio_as_aio` to run Trio code from within your
 asyncio-flavored functions. This is referred to internally as a "sync loop"
-(``SyncTripEventLoop``), as contrasted with the "async loop" that you use
+(``SyncTrioEventLoop``), as contrasted with the "async loop" that you use
 when you start from an existing Trio run. The sync loop is implemented using
 the ``greenlet`` library to switch out of a Trio run that has not yet completed,
 so it is less well-supported than the approach where you start in Trio.

newsfragments/130.bugfix.rst

@@ -43,7 +43,7 @@
 code (asyncio: ~8000) but passes the complete Python 3.6 test suite with no
 errors.
 
-``trio_asyncio`` requires Python 3.7 or better.
+``trio_asyncio`` requires Python 3.8 or later.
 
 Author
 ======

newsfragments/134.bugfix.rst

@@ -108,8 +108,10 @@ class BaseTrioEventLoop(asyncio.SelectorEventLoop):
     Arguments:
         queue_len:
             The maximum length of the internal event queue.
-            The default is 1000. Use more for large programs,
-            or when running benchmarks.
+            The default of None means unlimited. A limit should be specified
+            only if you would rather crash your program than use too
+            much memory, because it's not feasible to enforce graceful
+            backpressure here.
     """
 
     # This code implements a semi-efficient way to run asyncio code within Trio.

newsfragments/137.feature.rst

@@ -1,3 +1,3 @@
 # This file is imported from __init__.py and exec'd from setup.py
 
-__version__ = "0.13.0+dev"
+__version__ = "0.14.0"